GNOME Bugzilla – Bug 590726
Use _NET_WM_STATE_HIDDEN state solely for iconic windows
Last modified: 2021-07-05 13:47:42 UTC
This discussion was started on http://bugzilla.openedhand.com/show_bug.cgi?id=1443; the orginal report and Owen's additional comments: Currently iconic windows cannot be deiconified following the ICCCM spec; the specification regarding this is insufficient. Section 4.1.4 of the specification (http://tronche.com/gui/x/icccm/sec-4.html) states: IconicState - The client's top-level window is iconic (whatever that means for this window manager). The client can assume that its top-level window is not viewable, its icon_window (if any) will be viewable and, failing that, its icon_pixmap (if any) or its WM_ICON_NAME will be displayed. In case of Metacity-Clutter, we retain the iconic windows mapped (so that their live contents can be used in places like application and workspace switchers), and hide them in the compositor. This is entirely withing the requirements of the specification. Regarding the de-iconifying windows, the spec states: Iconic -> Normal - The client should map the window. The contents of WM_HINTS.initial_state are irrelevant in this case. This is not an adequate mechanism to match the broad concept of IconicState that the specification introduced earlier; since in our case iconic windows remain mapped, the map operation (which is what gdk does) is a NOP, so the WM has no way of knowing the window should be de-iconfied. This might not be immediately obvious because windows are normally iconified and de-iconfied manually, at which point the window is normally is also raised to forefront, which triggers the deiconification. In order to fix this issue, we need a more reliable mechanism to request de-iconification of a window, and this would need to be introduced both into the WM and any relevant toolkits. Owen's comments: One candidate would be to request removing _NET_WM_STATE_HIDDEN through the normal mechanism for changing _NET_WM_STATE. (This doesn't work currently at least with Metacity/Mutter, but would make sense.) _NET_WM_STATE_HIDDEN is pretty strongly identified with "minimized" - even without live-hidden-windows, you can't use IconicState for this because windows on other workspaces are IconicState as well. (see http://bugzilla.gnome.org/show_bug.cgi?id=586664).
Created attachment 139857 [details] [review] Patch to restrict the semantics of _NET_WM_STATE_HIDDEN to minimized windows I am attaching a patch that (a) limits _NET_WM_STATE_HIDDEN to set it only when a window is in a minimized state, and (b) interprets requests via the _NET_WM_STATE protocol that include _NET_WM_STATE_HIDDEN as request to minimize/unminimize given window.
Patch looks reasonable to me, but it seems to me that we need: - A patch for GDK that considers windows that are *either* _NET_WM_STATE_HIDDEN or IconicState to be iconified, and that sends a client message rather than XMapWindow for windows that are !IconicState but hidden. (Or always sends the client message in addition to XMapWindow) - A patch for the wm-spec that clarifies NET_WM_STATE_HIDDEN, describes using it to deiconify, and describes handling of compatibility considerations on the applicatin and window manager side. Before we'd want to go ahead and land this. Also, should it be possible to set _NET_WM_STATE_HIDDEN initially the same way that other state flags can be set?
(In reply to comment #2) > Patch looks reasonable to me, but it seems to me that we need: > > - A patch for GDK that considers windows that are *either* > _NET_WM_STATE_HIDDEN or IconicState to be iconified, and that sends a client > message rather than XMapWindow for windows that are !IconicState but hidden. > (Or always sends the client message in addition to XMapWindow) I attached a patch to the associated bug http://bugzilla.gnome.org/show_bug.cgi?id=586664, should have mentioned that.
(In reply to comment #2) > - A patch for the wm-spec that clarifies NET_WM_STATE_HIDDEN, describes using > it to deiconify, and describes handling of compatibility considerations on the > applicatin and window manager side. After some more thought, I am wondering whether we should not define a new state atom _NET_WM_STATE_ICONIFIED for this, so as to avoid any legacy baggage with _HIDDEN: * An additional marker for a conforming WM to (un)set when it (de)iconifies a window, * Conforming clients could opt to use the _NET_WM_STATE_ICONFIED via the _NET_WM_STATE protocol to request iconification, but it would be equivalent to using XIconifyWindow(). * Conforming clients would be required to use the new state as the authoritative way of determining whether the window is in an iconic state when a conforming WM is running.
Should have been clearer on the legacy baggage; if we define new state atom, the clients can unambiguously determine whether the WM supports it from the _NET_SUPPORTED property the WM sets on the root, we do not get that from reusing the _NET_WM_STATE_HIDDEN atom for this, and will find it lot harder to ensure seamless backward compatibility.
Created attachment 139924 [details] [review] Updated path using _NET_WM_STATE_ICONIFIED Attached is a patch that uses new _NET_WM_STATE_ICONIFIED to avoid legacy issues. This patch also handles the initial value of this property.
So what's with this? Do we still want / need it?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.