gtk under wayland never sets the iconified window state

[totaam]

https://gitlab.gnome.org/GNOME/gtk/-/issues/67 There is no minimize support in either the xdg-shell or the gtk-shell protocols (..) we should remove the implementation from GdkSurface (and GdkWindow, in GTK3)

Looking at the commits, they've renamed (de)iconify to (un)minimize: https://gitlab.gnome.org/GNOME/gtk/-/commit/c296101a2f3a8cd3b016ea0466f975c183641e3f and completely removed the state change! (renaming is also a strange choice instead of just updating the documentation, since iconify has been used for decades in GTK code..)

Here's the workaround adopted by firefox: https://phabricator.services.mozilla.com/D41219 (and it may no longer work in the future?)

We need to know when the window is minimized. Normally, a minimized window consumes zero bandwidth. Under wayland it will continue to eat bandwidth for no good reason.

---

They just keep on removing simple windowing features (ie: window absolute positioning, CSD vs SSD, systray, network transparency, etc) rather than implementing them, what's going to be left? This is getting really bizarre. How can it ever replace X11? (the clipboard is almost usable for us now... after only 10 years)

Embrace and extend is a very successful approach for a reason, this is more like shun and hinder. This fragmentation is probably why there will never be a year of the Linux desktop. Reminder: Microsoft's windowing API has barely changed in 30 years, creating a window and minimizing it still works the same: SW_MINIMIZE.

/rant

[totaam]

Perhaps this extension will eventually get merged, then GTK may wrap it, then a few years later we may be able to finally use it: surface-suspension: Add surface suspension protocol This protocol provides the ability for clients to know when their surfaces are suspended or restored.

[totaam]

Fun read: How Does One Create A Gtk+ Application?: Now I hear we are in for another round of breaking rendering because of some Wayland deficiency Also some harsh language here: Why do we keep building rotten foundations?, ie: GTK is a foundation library. And it’s rotten, and they know its rotten. And they keep tearing it down and replacing it – with another rotten foundation. And we all suffer because of it But the core points remain valid, sadly.

[totaam]

More wayland restrictions: Wayland on desktops has no official way to position windows from the client See How to use GTK4 to read windows changed X and Y on Move/Resize Events?

[MayeulC]

More wayland restrictions: Wayland on desktops has no official way to position windows from the client

IMHO, this is more of a feature than an issue, I cannot think of a single use-case for it, and applications that do it are very annoying to me (especially as I now use a tiling window manager, I have been using sway for > 4 years). Less annoying than applications that move your mouse cursor, though. I have this old X application that I use professionally, that really wants to move my mouse to the "OK" button on its dialogs, but messes up the calculations badly (possibly due to a multiscreen setup?) and sends the cursor in some random place when a pop-up appears.

Placing windows is the compositor's job, so is placing the mouse cursor. At best, I think apps should be able to request exemptions (fullscreen, pointer confinement).

Edit: one exception I can think of is displaying OSDs, taskbars, etc. wlr-based compositors have layer-shell for this.

[MayeulC]

We need to know when the window is minimized. Normally, a minimized window consumes zero bandwidth. Under wayland it will continue to eat bandwidth for no good reason.

I'm no expert at this (you seem to be much more well-versed than I am), but I am pretty sure that on wayland, it's usually the compositor that tells you when to render.

Additionally, the compositor might not even want to show new frames for you. Your application might be off-screen, minimized, or hidden behind other windows; or only a small thumbnail of your application is being shown, so they might want to render you at a slower framerate to conserve resources. For this reason, the best way to continuously render frames in a Wayland client is to let the compositor tell you when it's ready for a new frame: using frame callbacks.

[totaam]

Placing windows is the compositor's job

Many, many applications want to place their windows relative to other windows. etc The fact that open-source toolkits focus very narrowly on open-source applications exclusively is nothing new, unfortunately.

the compositor that tells you when to render.

That's not what we want. By then it is too late: we can't render something we don't have.

Also, AFAICT, GTK does not expose this frame callback.

[MayeulC]

Thank you for taking the time to reply.

Also, AFAICT, GTK does not expose this frame callback.

Indeed, that would be an issue. I looked around a bit. From what I could find, it may be available in GDK 3.9, but possibly not on the GNOME compositor side?

Anyway, looking more into it, you can at least get a raw wl_surface from GDK.

That would allow you to request a callback, even if it requires talking with low-level wayland APIs. Then you could use a sliding window (which could be made of n=2 callbacks, or probably better, a fixed duration ~16ms or the frame time, or a mix of all that) to compute the framerate the compositor asks for (In my opinion, the GDK frame clock should probably request and compute that itself).

I'm not sure if there are better options; I am just a satisfied Wayland user, and longtime xpra user. But I'd like to look into this a bit deeper if I have the time to.

That's not what we want. By then it is too late: we can't render something we don't have.

Aren't you always going to miss a few frames, whatever the method? When ramping up the transmitted framerate, the minimal latency is one round-trip (plus processing), which would likely be more than 16ms. That also applies when un-minimizing. I would just display the last known frame for a few frames. I don't think we can do better than a few heuristics here.

Many, many applications want to place their windows relative to other windows. etc The fact that open-source toolkits focus very narrowly on open-source applications exclusively is nothing new, unfortunately.

Well, I still don't have a single valid example in mind, open or closed-source (that's actually something I would actively disable on X11 if I could, but that's my own opinion). I can understand an initial placement hint for sub-windows, though that's more of a nicety than a requirement. I think it is achievable with positionners from xdg-shell, at least in part.

The original rationale is that surfaces shouldn't assume how they are displayed (they could be displayed multiple times, like if two xpra clients connected to the same server, or on multiple screens, or positioned in a VR space like SimulaVR does).

---

Now, about the original issue, I didn't quite understand the description; is it the reason why xpra doesn't display a system tray icon under Wayland? I don't use GNOME, but I think they completely removed system tray icons, and I think a nice replacement is libappindicator, but you are probably aware of all of that.