Support Wayland natively

[ubruhin]

SUMMARY

Currently in our official AppImage, Flatpak and Snap package we explicitly disable Wayland due to several issues, forcing LibrePCB to be run with XWyaland instead of natively. However, for long term we should fix the issues and enable native Wayland support in those packages.

Generally LibrePCB does run on Wayland, which is the case when compiling LibrePCB from source. However, I observed several issues:

• [ ] Window sizes/positions are not saved/restored, each window is opened with its initial default size/position. This is very annoying when using LibrePCB productively.
• [ ] Switching between different windows (control panel, board editor, schematic editor) with the provided toolbuttons does not work. This is not really critical and maybe no solution is needed for now due to a planned UI refactoring. But it would still be interesting to know why it doesn't work and how we could get it working.
• [ ] Window icons cannot be set.
• [ ] Strange rendering artifacts in the 3D viewer, making it basically unusable.
• [ ] Not sure anymore, thus needs to be checked: Does the clipboard work properly?
• [ ] In the AppImage, the Wayland Qt plugin is not shipped, causing the application to terminate when forced to run on Wayland. Would be nice to ship both the wayland and the xcb plugin so the AppImage at least works more-or-less instead of just terminating (see #1242).

Maybe there are more issues, so we need to do some additional testing on Wayland to find them.

SOLUTION

1. Try to fix all the issues listed above.
2. If Wayland support works well, make the AppImage, Flatpak and Snap package running natively on Wayland.

[GravisZro]

AppImages/Flatpack/Snap seem like the wrong distribution model. Is there a reason to avoid making distro packages?

[ubruhin]

AppImages/Flatpack/Snap seem like the wrong distribution model.

Why? How is it related to Wayland? Our problem with Wayland is Wayland itself and/or it's interaction with Qt, not the distribution packages.

Is there a reason to avoid making distro packages?

Because it's 100 times more effort to build for example a *.deb, and then you covered only a few distributions and are still not in the official repositories. I have no time for such an inefficient packaging workflow. But of course I'd love to see some package maintainer building and distributing native distro packages (which actually do exist for several distros, e.g. NixOS). There's nothing which prevents people from doing this.

With AppImage/Snap/Flatpak we can provide packages for basically any Linux distro in relatively short time, typically updates are deployed to users within a few hours after we create a new LibrePCB release. But that's all offtopic here, if there's an interest in discussing this I'd prefer opening a forum thread.

[bubelov]

Distro packages are better but they're pretty labor intensive and there are simply too many distros to support. It's cool if someone is willing to maintain a few distro-specific packages, but I think there should always be a universal option.

AppImages, Snaps and Flatpaks add an extra abstraction layer and you often need to install tons of external deps, which is not ideal, and I guess it's the main reason why some people don't like those options.

The best option IMO is providing an universal Linux binary. I'm not deeply familiar with the low level stuff, but I guess it can be achieved with static linking or switching to musl. I think Bitcoin Core is actually QT-based and they do provide universal binaries, so it's certainly not impossible.

[BuFran]

I can take the effort for *.deb packaging (Ubuntu, Mint, Raspbian ...), I have own server with a lot virtuals/ build system so i can deploy (not test) binaries for any free system running x86 or raspberry ARM. It should not take much time, the project is well organized, it is only one more CI run per architecture and little edits on CMakeLists needed to generate correct package with all translations. Only effort will take discussion of deployment (my server is not on public IP due to security concerns so it can't be connected with GitHub directly)

The standalone build is not so easy as you say, it is a LOT of work, because the full Qt library should be recompiled by own and all of the build dependencies should be changed.

BUT: If there is as much problems with wayland as I can read here, the deb package will be unusable for users, when they use wayland. This issue should be fixed (or checked) first. So I am investigating how to load wayland over plain x11 now :-)

[ubruhin]

Please please open a separate thread for discussing distro packaging - it is offtopic here :wink:

BUT: If there is as much problems with wayland as I can read here, the deb package will be unusable for users, when they use wayland. This issue should be fixed (or checked) first.

Exactly! Wayland issues are not related to packaging at all.

[GravisZro]

My appologies, I had taken, "In the AppImage, the Wayland Qt plugin is not shipped" to mean packing was an issue.

About fixing Wayland, whenever there are inexplicable bugs in a project, my very first approach is to ensure that everything explicitly deleted is always immediately set to nullptr. This is a surefire way to identify 99% of memory issues. I recently fixed https://github.com/Robotips/uConfig which had mysterious issues but a commit two years ago swapped two lines and it had been running using deleted memory until a few weeks ago.

I'm not saying this is the issue but if the behavior is inexplicable then it very well could be.