Closing of popup window when focus is lost not wanted under Sway

[hissssst]

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

Environment and versions

• Versions of syncthingtray, qtutilities and c++utilities: 1.2.3, 6.8.0, 5.19.0
• Qt version: 5.15.5
• C++ compiler (name and version): …
• C++ standard library (name and version): …
• Operating system (name and version): Linux, NixOS (package syncthingtray-minimal)
• WM: Sway 1.7

Bug description
When I click on tray icon, popup window is opened. But this window closes, as soon as any other window gets focused.

recording.mp4

Steps to reproduce

1. Install Sway wm and bar which supports tray (like Waybar). Run them with syncthingtray in tray.
2. Click on icon. Popup window gets opened
3. Move focus to popup window. Popup window is responsive and opened.
4. Move focus to any other window. See that popup window gets closed

Expected behavior
Popup window does not get closed when other window is focused

Additional context
I think this is relevant to Wayland and Sway, because they do not allow regular windows to open in overlay in any place they want. There is a special protocol called xdg-layer-shell which allows this behaviour, but I don't know if Qt works with it out of the box.

Anyway, if the protocol won't be supported by the syncthingtray, I think it is worth to fix the bug

[Martchus]

Popup window does not get closed when other window is focused

Normally that is the desired behavior. If you focus (not just move your cursor above) another window, than the tray menu is supposed to close. It behaves like any other (context) menu in that regard. It is conceivable to implement a mode where a normal window is used instead of a menu if that's not wanted. I suppose a "pin" icon to keep the window open all the time would be generally nice.

Note that in the KDE wayland session the closing behavior actually makes sense and the only issue is that the window isn't positioned correctly. The positioning issues are due to shortcomings in the Wayland protocol. In your case even the window size is ignored which is an additional problem.

---

There is a special protocol called xdg-layer-shell which allows this behaviour, but I don't know if Qt works with it out of the box.

It does not. Maybe I'll take the extra effort of making use of https://github.com/KDE/layer-shell-qt at some point but it hasn't happened yet. I'm not that keen on spending time just to cope with Wayland's limitations (when one can just use a fully featured display protocol instead).

---

At some point I have been testing Syncthing Tray under Sway and with the following workaround it was ok to use it: https://github.com/Martchus/syncthingtray#workaround-positioning-issues-under-wayland

---

Anyway, if the protocol won't be supported by the syncthingtray, I think it is worth to fix the bug

Not sure what you exactly mean by that. I'm generally open for PRs improving Wayland support but my own time/motivation to work on it is limited.

Note that what you're asking is clearly not a bug but a feature request. You cannot consider lack of support of a certain platform as bug when it simply has never been implemented.

---

The video you've attached does not play in Firefox (and possible also not other players). I suppose using a more common chroma subsampling would help (e.g. with ffmpeg one would use -pix_fmt yuv420p).

[hissssst]

The video you've attached does not play in Firefox

It's a firefox bug, I experience the same. You can download the file by the link, or open it in chromium-based browser (I use ungoogled-chromium).

Note that what you're asking is clearly not a bug but a feature request

Alright, not a problem. I didn't know that Wayland is not supported.

the following workaround it was ok to use it:

Thank you!

I'm not that keen on spending time just to cope with Wayland's limitations

Alright

If you focus (not just move your cursor above) another window, than the tray menu is supposed to close

Hmm, my other tray menus remain opened when I focus other windows.

---

Considering the feature, perhaps it would make sense to implement an option which won't close a popup window when any other window is focused? What do you think, is it possible?

[Martchus]

Considering the feature, perhaps it would make sense to implement an option which won't close a popup window when any other window is focused?

Yes, that's what I meant with "It is conceivable to implement …".

What do you think, is it possible?

It might be a little bit complicated to dynamically switch between using a menu and a normal window. However, maybe it is sufficient to just change the windows flags/attributes regardless whether QWidget or QMenu is used. One has to try out and see. Maybe it is as easy as adding a "pin"-button and setting window flags/attributes accordingly (and saving the state of the button in persistent settings).

[Martchus]

I've been implementing pinning as an experimental feature. To test it, you need to start syncthingtray with the --wip flag.

It is not nice that the window shorty disappears when enabling pinning but I suppose it is unavoidable.

I'm also wondering whether it makes things much better because now closing becomes a bit unintuitive. One can close the window again by unpinning or simply via the task bar like any other window so it is supposedly still acceptable.

I've also tested it on Sway and I must say with the mentioned workaround from the README it is already usable without pinning as one can move the cursor from the tray icon to the window without focusing any other windows. (I find it a bit strange that Sway automatically focuses a window on mouseover.)

[Martchus]

I've been experimenting with layer-shell-qt. It would generally work but it affects all windows (also the settings dialog, welcome/wizard dialog, about dialog). Maybe I'm missing something but as long as I don't know how to overcome that limitation that would be a deal-breaker for using layer-shell-qt.

[Martchus]

KDE devs told me:

Qt only supports one shell type per application
So you can't mix layer-shell with xdg-shell

That basically means the limitation isn't easy to overcome (as there can only be one app per process and using multiple process would be too much effort).

[Martchus]

There's actually a WIP change for allowing multiple shells in Qt: https://codereview.qt-project.org/c/qt/qtwayland/+/444724

[Martchus]

It was nevertheless made clear that layer-shell-qt is not supposed to be used for use-cases like this one. So even if those limitations would be resolved it remains questionable whether layer-shell-qt is the API to use - most likely not.

---

In the chat I've also stated my opinion about Wayland. While I try to like it and while it serves well for certain use cases I'm not sure whether the GNU/Linux desktop is heading in the right direction with Wayland:

On X11/Windows/Mac one can simply query the mouse position, available geometry and set the window position. These building blocks can be put together to achieve proper positioning of a tray application. It may not be perfect but works sufficiently well in practice. So I wouldn't consider it a hack.
Wayland missed some of these building blocks so naturally I'm checking what else is there to fill the whole. However, it seems like Wayland's philosophy is not to provide basic building blocks to allow for a variety of differently behaving applications. They rather want to provide a dedicated API for every use case Wayland developers deem useful. That's quite problematic because it limits application developers and ultimately users that may have more use cases in mind.
And not having certain APIs obviously breaks compatibility which is also very problematic on its own (even if apps could be adjusted).

[Martchus]

Maybe this proposal would be the right place to contribute at this point: https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/54

[Martchus]

The discussion in the mentioned proposal is still ongoing. However, I doubt we'll be able to achieve anything there as it is about the smallest common denominator between different DEs and GNOME rejects the idea.

[Martchus]

The pinning didn't work very well. I decided to allow a normal windowed mode instead. Then Syncthing Tray behaves like any other application (which you still might want to tweak on compositor level). See the commit (message) for details. Since this is as good as it gets with Wayland I would suggest to close this issue then.

---

Let me conclude with a message I've already felt compelled to write on the KDE development channel (which is a continuation of my thoughts mentioned in #157 (comment)) :

I must say that when I've started using GNU/Linux several years ago I was very enthusiastic about it. I was hoping certain problems would improve. Well, many things did indeed improve and I generally like KDE's Wayland session using it as daily driver for certain use cases. However, not valuing compatibility and restricting developers and users in their creative use of the platform really drives me away from it at the same time. Windows provides me as developer more freedom - without having to ask Microsoft all the time to agree with me to add a feature to Windows itself. And when I started to use GNU/Linux I particularly liked it due to this kind of freedom - which now weirdly even Windows seems to be better at (at least when it comes to the graphical UI).

Don't interpret this as "we should stay on X11 forever". I personally don't care much about X11 vs. Wayland. I care about the GNU/Linux desktop as a platform. And I care that whatever tech is used under the hood values compatibility and use cases of application developers and their users. The Windows desktop is moving forward by introducing new features without breaking features/applications that previously worked. I find that way of moving forward much better as an application developer (who doesn't need to spend additional time on porting or has to tell users that it simply cannot be done anymore) and as a user who just doesn't run into problems using the desktop and applications.
Under GNU/Linux I'm on the other hand now in a quite bad place. If I want scaling to work nicely with different factors on different screens and no scaling-related bugs in Plasma I better use Wayland. Unless I want fractional scaling. If I want to play some games in my steam library I better switch back to X11 because they're broken in XWayland because it supposedly broke compatibility of certain APIs. This is just one example. If I was an inexperienced user, I'd probably already given up using the GNU/Linux desktop.