FR: Wayland positioning once and for all

[midirhee12]

I've read the note left here. But I think there's actually some hope to resolve this issue.

It just so happens that nm-applet (and possibly others) is achieving this. I'm not exactly sure how, but I'm trying to look through their git repo here to find out.

If I figure it out, I'll try to write up a PR for the change.

I thought it would be good to keep up an open issue in the meantime to talk about this. I think this will require at least some level of documentation. And it would be nice to also show the process for other tray applet projects to achieve proper Wayland support.

Relevant components

• Standalone tray application (based on Qt Widgets)
• Plasmoid/applet for Plasma desktop
• Dolphin integration
• Command line tool (syncthingctl)
• Integrated Syncthing instance (libsyncthing)
• Backend libraries

[midirhee12]

It looks like this is the release that featured proper Wayland support:
https://gitlab.gnome.org/GNOME/network-manager-applet/-/blob/main/NEWS#L134

I'll try to look through any relevant commits to that version (network-manager-applet-1.8.24).

[midirhee12]

Here's the version commit:
https://gitlab.gnome.org/GNOME/network-manager-applet/-/commit/ce203dd7e99c9c943cb24756d25968781fb1dbd3

So the Wayland change would have had to be before that.

[Martchus]

I'm curious how they have achieves this. Maybe I'll have a look at their git history later.

My current state is that this is not working, e.g. see #170 (comment) and further links mentioned there.

If they use layer-shell-qt to achieve this then this is unfortunately not possible in case of Syncthing Tray because of limitations of Qt, see #157 (comment) and subsequent comments.

[midirhee12]

Hmm, it looks like they are using GTK4 at the moment. So it doesn't seem like there's much of a solution for Qt. I guess the next move is to create an issue with Qt then.

[midirhee12]

Hmm, I think this is more of a Qt problem than a Wayland problem then since GTK4 has a solution for this. Also, sadly the WIP change mentioned in #157 has been put in an abandoned state, so there will be no further development there. I wonder if there's another angle of going about this.

[Martchus]

I think Qt devs are already aware of the issue (see e.g. this abandoned change: https://codereview.qt-project.org/c/qt/qtwayland/+/444724) but lack the resources/motivation to go forward with this. It would supposedly be quite some effort and considering the small amount of users using Wayland (already GNU/Linux users in general are a small fraction) it is likely not worth it. Maybe some Wayland fans will help with that at some point.

[Martchus]

I did a little bit more research and must say that this looks interesting: https://github.com/iridescent-desktop/qt-wayland-shell-helpers

But first I'll also have to check what nm-applet/GTK4 are actually doing under the hood.

[midirhee12]

Good find! That does look interesting.

I think this is the only relevant change to nm-applet (unless there were other commits to improve Wayland support made before v1.8.24) is:
https://gitlab.gnome.org/GNOME/network-manager-applet/-/commit/db996b3b73095152120e0e73a0c2961cf7f5aef3?merge_request_iid=64

This issue might also be relevant.

Also, I'm a bit confused on the Qt change. They don't want to merge the change b/c it breaks the private API? I don't see why that would matter. Couldn't they just hold off to merge until the next breaking change instead of abandoning it?

[Martchus]

It just so happens that nm-applet (and possibly others) is achieving this.

That seems very wrong. I've just tried nm-applet 1.32.0 as provided by openSUSE Tumbleweed under KDE Plasma's Wayland session. It works. However, it also looks like nm-applet developers just threw our their "custom" interface that was previously shown on a left-click on the icon. Now there's only one unified menu based on the D-Bus API for tray icons/menus. That means now it doesn't matter anymore whether you do a left- or a right-click. You just get the same dumbed-down menu in both cases.

I could also dumb-down Syncthing Tray to only use the D-Bus-API. (The right-click menu of Syncthing Tray already does this, by the way. Thus the right-click menu is also not affected by positioning issues.) However, I don't want to do that. It would mean being able to only use menu entries. The entries could have icons and check boxes but nothing more. It would not be possible to embed a list view.

I think this is more of a Qt problem than a Wayland problem then since GTK4 has a solution for this.

Considering my findings by testing nm-applet I don't think GTK4 has a solution for this.

I also don't think we have a "Qt problem" here. The limitation of Qt I have mentioned is that it only supports one Wayland shell at a time and that there's no general support for layer-shell except though 3rdparty libraries. However, that is not a problem but simply a feature that hasn't been implemented yet. (I don't like to call all conceivable feature requests "problem".) I would rather call Wayland the problem by not providing simple APIs that most (if not all) other graphical desktop environments/platforms provide. It breaks with established conventions and practices for in my opinion no good reason requiring other people to do additional work. And then the other people that need to do additional work are even called the problematic party… I personally must say that definitely lowers my motivation to do any additional work to support the Wayland platform. I could fully understand why Qt developers abandon certain efforts regarding Wayland as well.

---

Couldn't they just hold off to merge until the next breaking change instead of abandoning it?

Likely they had better things to do. So they didn't come back to this change in time for the next major release.

---

I will close this issue again because even if Qt had support for using multiple shells or one can use a 3rdparty library for this there's still one problem with this: That's not the intended way of using layer-shell. When I mentioned my idea to use layer-shell for Syncthing Tray the developers said that I shouldn't do it. They were basically saying it would be an abuse of that protocol. I'd still accept a contribution using layer-shell and might come up with a hack myself when I get really bored. However, I would not make a fix plan to work on this. If you want to share more information about recent developments you can still comment here and I might consider reopening the issue.

By the way, at the point I'm writing this no shift of opinion has happened in https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/54. So the parties "controlling" the GNU/Linux desktop still don't like the idea at all I have proposed there. I have also not heard anything about allowing positioning of top-level windows under Wayland. So I assume this is still not wanted by Wayland developers.

[Martchus]

Interestingly, if one launches the very same version of nm-applet under the very same version of KDE Plasma but using X11 then one gets back the "custom" menu on left-click and also the right-click menu differs then. So nm-applet has only been dumbed-down when running under Wayland. That's an interesting approach but likely not that useful for Syncthing Tray (where one can already show the "custom" GUI just as normal window).

[Martchus]

Just for the record, the popular player MPV has a similar issue: mpv-player/mpv#8692

A proposal is mentioned there (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/72) but the URL doesn't load for me. Likely it was rejected anyways.

[Martchus]

By the way, I'm still tracking this. So you may want to subscribe #170 where I've just added a comment. (I haven't added a comment here because this ticket is just a duplicate of the other one.)