Wayland support

[ManuelSchneid3r]

This is a parent issue to agglomerate all the wayland issues.

Wayland and Qt Wayland are far from mature. I know Wayland is quite popular and I'd like to support it but working with it is simply a pain and incredibly (and I mean incredibly, honestly other platforms just work out of the box) time consuming. Thats why I decided to not support Wayland officially.

The minimum OOTB experience I expect to consider supporting Wayland again is (at least):

• xdg-desktop-portal org.freedesktop.portal.GlobalShortcuts Skycoder42/QHotkey#89 (Hotkeys)
• Window moving
• Pasting
• OpenUrl QtBug worked around using xdg-open
• Decorations

[johanhelsing]

Hey, previous Qt Wayland maintainer here.

Since a lot of potentially different issues were closed and linked to this one, I'll try to summarize what I know.

Most of the segfault reports linked to this one seems to be due to X11 code for the hotkey manager being called directly on linux without checking whether wayland or x11 was used. It was recently fixed in #804 . So these crashes should not be an issue anymore.

If you have problems after that patch, it's probably a good idea to send logs with

export QT_LOGGING_RULES="qt.qpa.*=true"
export WAYLAND_DEBUG=1

Set in the environment, which should hopefully give a lot more information about what went wrong.

Also note that many X features do not have a direct replacement in wayland, two of which are important for apps like Albert:

1. Registering global key listeners is not possible on Wayland

Allowing apps without window focus to listen to key strokes is considered insecure on Wayland. This is in order to have the possibility to sandbox apps that you don't trust completely. I.e. similar to what android does. Unfortunately there is (as far as I know) no standard way for apps to request this sort of permission. This means that each compositor handles global shortcut key configuration in their own way, and you need to check how it's done on your compositor and make it run albert on some key combination.

TL;DR: Global key shortcuts are configured in the compositor on Wayland.

2. Positioning a window on the screen is not allowed in xdg-shell (the desktop wayland protocol).

Qt has APIs for positioning a window, i.e. QWindow::setPosition, however this is not possible to implement on Wayland, and it currently does nothing. Global window positioning is more or less considered evil, the reasoning being it should be up to the compositor to decide how to arrange windows. This has caused lots of issues for Qt, as it relies quite heavily on global positioning for placing menus for instance. There are lots of really ugly hacks in QtWayland to adhere to the relative positioning with a strict hierarchy that Wayland requires.

As for albert, I guess the issue is that you probably want the window to be handled somewhat specially and always appear in the same position (i.e. centered), which may not be what the compositor has in mind for it. i.e. it may just put the window somewhere where there is free space. Or tile it, or whatever. Solving this is not currently possible without resorting to some kind of hack, like asking to be maximized and draw a mostly transparent window with albert centered in the middle, and you're still not guaranteed the compositor will honor your request to be maximized.

There was some effort done in trying to solve these kinds of issues properly by creating an alternative wayland shell protocol, https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-layer-shell-unstable-v1.xml that did allow some of these things. It's implemented in Sway, and even some prototyping was done to support it through Qt. If memory serves me, some of the other launcher apps (not Qt-based, though) use this shell to work properly on sway.

Another way would be to try to write an extension for xdg-shell to add absolute window positioning. This would likely be easier to implement and get merged into Qt, but getting it into wayland protocols will probably be a lot harder.

TL;DR: Wayland is the only desktop that doesn't allow apps to set their own screen position, which means neither Qt nor albert has any control over where the albert window appears.

The pragmatic solution

Most wayland compositors support X11 apps through XWayland. If you launch albert with QT_QPA_PLATFORM=xcb albert to run it through the X protocol, you will probably be allowed many of the luxuries that are considered insecure or evil on Wayland, but also have some of its drawbacks, like poor hidpi handling. For albert, it looks to me as if X11 is currently the lesser of two evils.

If someone wants to work on this, I would recommend asking the sway developers (they've been involved in lots of great other standardization work for the desktop, like middle-mouse pasting and server-side window decorations) what they think and if there's anything you can do to help standardization and adoption of the protocols needed to get albert working properly on Wayland.

[tukanos]

@johanhelsing excellent summary. I may take wisdom to a different project. Thank you.

One question:

Global window positioning is more or less considered evil, the reasoning being it should be up to the compositor to decide how to arrange windows.

Why should "compositor to decide how to arrange windows."? The logic here is avoiding me.

You have many use cases where you want to have windows in certain places like monitoring, logs, mails, launcher, etc. Why those applications can not sent hints that the user wants to have it there? The compositor should, if possible, listen to the wishes of the user.

[johanhelsing]

Why should "compositor to decide how to arrange windows."? The logic here is avoiding me.

I can only speculate, personally I think a soft hint would have been great, but these are some possible reasons:

• You can write really weird compositors and still have things like popups and menus working. VR-compositors, tiling compositors, devices with non-rectangular screen (watches). They are a lot easier to write when the client doesn't assume you have a rectangular screen and they can pop up wherever they want. Then "please put me 100 pixels to the right of this parent" makes a lot more sense than please put me at 340x400.
• Maybe there is some resistance against it due to the fact that if it was allowed, even as an optional hint, kwin/qt and some others would probably immediately adopt it to solve all the issues Qt has been having with it, and there would be less focus on fixing relative positioning bugs in Qt for instance, making relative positioning-only compositors second-class citizens.
• More options means more things to support/maintain and more ways for bugs to appear

Tiny disclaimer: I haven't worked with Wayland or Qt for a couple of years, so some of this might have changed recently. I suspect the extension standardization process is a lot easier now than it used to be for instance.