Set "suspended" when a surface is minimized

[ids1024]

This seems for an SDL XWayland client to restore fullscreen after unminimize, it needs to see the _NET_WM_STATE_FOCUSED state get set and unset.

This is a somewhat awkward way to do this. I'm not sure if the Wayland suspended flag should be treated as equivalent to _NET_WM_STATE_FOCUSED? If it's meant to be, the way it's defined in the protocol doesn't quite seem right.

#1510

[Drakulix]

That seems like a very clunky way to do this, how about doing this in an idle-callback, like we handle the Activated-state?

In general we should send suspended (at least for wayland surfaces) in many more cases, e.g.:

• fullscreen surface in the way or window occluded by others
• screen-locker active
• non-visible workspace
• and of course minimized

I am not sure how that would interact with window previews though in both the Xwayland case and wayland case. In general X11-windows expect to be unmapped on minimize, which we already delay, because that obviously breaks window previews... _NET_WM_STATE_FOCUSED should probably be fine though.

In addition we also want to handle _NET_ACTIVE_WINDOW differently. Vlad told me at XDC, that SDL like to differentiate between "No window is focused" and "Another window is focused". So as long as a wayland-surface is focused, we should set _NET_ACTIVE_WINDOW to an offscreen x11-window we create. This will also require some changes to smithay's xwayland-code.

[ids1024]

Yeah, this PR is a bit "clunky"; which is why I left it as a draft. I think it should be a safe change as is, though there are other cases we want to change.

Doing it in an idle callback like that could be good.

In general X11-windows expect to be unmapped on minimize, which we already delay, because that obviously breaks window previews... _NET_WM_STATE_FOCUSED should probably be fine though.

Err, I guess I meant to say _NET_WM_STATE_HIDDEN here. Anyway...

Yeah. Setting _NET_WM_STATE_HIDDEN but not unmapping seems to be what Mutter does. So it should be safe since modern clients have been tested to work on Gnome, whether or not this is what the specs suggest should happen on minimize.

As defined in https://specifications.freedesktop.org/wm-spec/latest/ar01s05.html

_NET_WM_STATE_HIDDEN should be set by the Window Manager to indicate that a window would not be visible on the screen if its desktop/viewport were active and its coordinates were within the screen bounds. The canonical example is that minimized windows should be in the _NET_WM_STATE_HIDDEN state. Pagers and similar applications should use _NET_WM_STATE_HIDDEN instead of WM_STATE to decide whether to display a window in miniature representations of the windows on a desktop.

It says "would not be visible on the screen if its desktop/viewport were active...", so for this property at least, setting it for a window on a "non-visible workspace" doesn't sound appropriate. And probably not when blocked by a fullscreen window? Though the wording here is rather vague. I imagine other implementations don't.

https://wayland.app/protocols/xdg-shell#xdg_toplevel:enum:state:entry:suspended meanwhile is defined as:

The surface is currently not ordinarily being repainted; for example because its content is occluded by another window, or its outputs are switched off due to screen locking.

Which does seem to cover those cases, as while as minimized.

[Drakulix]

So it should be safe since modern clients have been tested to work on Gnome, whether or not this is what the specs suggest should happen on minimize.

Note that a lot of toolkits special case certain desktops.

[Drakulix]

It says "would not be visible on the screen if its desktop/viewport were active...", so for this property at least, setting it for a window on a "non-visible workspace" doesn't sound appropriate. And probably not when blocked by a fullscreen window? Though the wording here is rather vague. I imagine other implementations don't.

I'd be careful with that then, which means we probably want to split set_suspended and handle this differently between X11 and Wayland windows.