Make it Wayland ready

[zilti]

Right now, AppImageUpdate won't run on a KDE Desktop that is configured to use Wayland (env var QT_QPA_PLATFORM set to wayland).

I don't know Qt too well, so I don't know which version started supporting Wayland, and if it's feasible to switch to that version, but when that env var is set to wayland, AppImageUpdate will silently fail to start. There are two solutions:

• Compile it with a newer version that supports the wayland platform plugin;
• Add export QT_QPA_PLATFORM=xcb to AppRun.

[TheAssassin]

We're building against Qt 5.9.3 and could easily upgrade to Qt 5.10. The question is, would that "just fix" the issue? I presume we have to ship said wayland plugin simply, just like we do with xcb?

@probonopd did you have such issues before?

[probonopd]

No, my assumption was that applications written for X continue to run under Wayland thanks to some compatibility layer.

QT_QPA_PLATFORM set to wayland

Never seen that in real life. Is this the default configuration of any Linux desktop, as of today?

[zilti]

QT_QPA_PLATFORM was set to wayland as a default for a while in KDE. And applications not supporting that and instead failing silently was exactly the reason this default was reverted for now (which results in all KDE applications being run as xcb applications).

[probonopd]

Good. I expect Wayland to be an option once the oldest still-supported distributions use Wayland, but not before. When shipping applications to users on unknown target systems, we need to always shoot for the "lowest common denominator".

[qwertychouskie]

Can you not just ship both the wayland and xcb plugins?

[probonopd]

One could, but isn't shipping a wayland plugin kinda pointless when xcb works just as well, at least for the forseeable future (until xcb is no longer supported)?

[zilti]

Which would imo be a point for setting that variable to xcb.

[TheAssassin]

@zilti the thing is, AppImageUpdate doesn't have an "AppRun script", it just uses a symlink to the main binary. That's the big advantage of tools like linuxdeploy: they make those scripts mostly obsolete.

There must be a better way than setting such a variable. Shipping the other plugin seems like a better idea, if it fixes the issue and won't increase the size significantly, as it would provide native integration without having to deal with xwayland and its bugs etc.

[zilti]

Ah, I see. Tbf even with linuxdeploy - it has been a big help though - I have not yet been able to go without at least a simple AppRun script, since the stuff I packaged so far all needed env vars.

[TheAssassin]

That's perfectly fine, of course, we do it in some AppImages, too. But the "default way" shouldn't be adding scripts; if someone else wants to add some additional env var, things become complex to handle.

We already thought about allowing linuxdeploy plugins to create "hook/callback scripts" which are called by a "main" AppRun script (if available), which would mean we forcibly ship our own script and don't allow for completely custom scripts any more, but that's got more drawbacks than advantages (slower startup, additional complexity, not as obvious to packagers, ...).

We should continue the discussion in https://github.com/linuxdeploy/linuxdeploy-plugin-qt/. I'll open an issue there, and will reference this one. Hope you don't mind when I ping you there.

[TheAssassin]

@zilti did you get a chance to run the latest version and see if it "just works" now?

[zilti]

I did! It does not work though... Here's what it does:

$ export QT_QPA_PLATFORM=wayland
$ ./AppImageUpdate-x86_64.AppImage
AppImageUpdate version 1-alpha (commit 6f2d028), build 400 built on 2019-02-07 22:44:08 UTC
Failed to load client buffer integration: wayland-egl

qt.qpa.wayland: No shell integration named "xdg-shell" found
qt.qpa.wayland: No shell integration named "xdg-shell-v6" found
qt.qpa.wayland: No shell integration named "wl-shell" found
qt.qpa.wayland: No shell integration named "ivi-shell" found
qt.qpa.wayland: Loading shell integration failed.
qt.qpa.wayland: Attempted to load the following shells ("xdg-shell", "xdg-shell-v6", "wl-shell", "ivi-shell")
Could not create a shell surface object.

[probonopd]

Confirms my overall impression of Wayland, adding pain without much gain (for me). I'd say don't bother until we are forced to (= Xorg does not work anymore).

[TheAssassin]

The amount of libraries that would have to be added is quite large, yeah. And the files aren't available from "any" Qt distribution, you need to install extra files, etc.

I think we should drop support for it from linuxdeploy-plugin-qt again, or make it optional at least.