GNOME Bugzilla – Bug 122640
Tasklist misleadingly shows all actions as possible for minimized windows
Last modified: 2020-11-06 20:08:41 UTC
I noticed I can do all the usual actions on a minimized window. I think that by a usability point of view it is useless to have menu voices for actions that actually don't produce any tangible result (because there's not a visible window). Some actions are semantically incorrect, e.g. the action "Move": How can I move a window while it's hidden? (And in fact that action doesnt work) I think that the only valid action on a minimized window should be "Unminimize". Maximize, Rollup, Move and Resize are not usefull in a minimized window. Steps to reproduce the problem: 1. minimize a window 2. right-click on the minimized window
Created attachment 20052 [details] This screenshot shows what I'm talking about
Still relevant--updating appropriately.
Created attachment 25392 [details] [review] Disallow actions for minimized windows; messes up shaded windows
I have attached a patch which solves the original problem (although possibly in the wrong way?), but makes a FIXME in the code into an even bigger problem. So, two main questions: 1) The code I added to change the appropriate actions is in update_menu_state. It's possible that this belongs in wnck_window_get_actions, but I wasn't sure if the semantics of that function were "get the actions that are currently possible and make sense for this window" or "get the actions that are possible for this window at some time or another." The only place wnck_window_get_actions is currently called is from update_menu_state, so I guess it could go either way. 2) The only place that the is_minimized flag is set is in window.c's update_state, and it depends on either the _NET_WM_STATE_HIDDEN or WM_STATE iconic flags--unfortunately, shading the window will set both of those (and minimizing a window will not unset the _NET_WM_STATE_SHADED flag). Thus it is impossible to distinguish a shaded window from a minimized one. update_state has a FIXME about this, but with this patch, not only does it display "Unminimize" instead of "Minimize", but "Unroll" also becomes disabled. (One can left-click the window in the tasklist, however, to unshade and activate the window and then continue as normal). Can we propose a _NET_WM_STATE_MINIMIZED extension for the EWMH spec so that we can differentiate between the two states of "shaded" and "minimized"?
Havoc? Comments?
Created attachment 28746 [details] [review] More complete (and updated) patch to disable non-sensical actions This new patch has been tested and works and is more complete (instead of just disabling certain actions on minimized windows, it also disables ones that don't make sense for shaded or maximized ones). This patch depends on the one in bug 107681, at least the part relating to the _NET_WM_STATE_MINIMIZED extension.
Hmm, see my reply on wm-spec-list - wnck_window_get_actions() is defined to return the menu items that should be sensitive. So modifying what it returns to get the sensitivity right definitely isn't what you want to do. Probably the bug here is in metacity for setting ALLOWED_ACTIONS improperly? Assuming libwnck is reading it properly, which isn't necessarily a given. There's a metacity bug that has something to do with this iirc, the metacity code here is a little bit screwy.
Created attachment 29008 [details] [review] Patch to have Metacity update _NET_WM_ALLOWED_ACTIONS This patch almost fixes the problem. The only problem that remains is that libwnck cannot differentiate between minimized and shaded windows very well, so "Unminimize" still appears (and is sensitive) for shaded windows (see the FIXME about this in libwnck's update_state function in window.c; also see the last three lines of libwnck's update_actions function in window.c where minimize/unminimize is unconditionally made sensitive). But to fix that we'll have to wait for the current EWMH spec discussion on that issue to be resolved. As long as shaded windows aren't used, the patch works fine. One part of the patch that seems a little odd to me is that I call set_allowed_actions_hint sometimes right after a call to recalc_window_features. recalc_window_features has a call to set_allowed_actions_hint inside it, but contained in an if that happens to never be true. I'm wondering whether it would be better to modify that if statement (and introduce a whole slew of new variables keeping track of old_minimized_state, old_shaded_state, etc.), or leave it as it currently is.
Moving to metacity since the patch is against it instead of libwnck...
Comment on attachment 29008 [details] [review] Patch to have Metacity update _NET_WM_ALLOWED_ACTIONS See also bug #94111 and bug #115247. #94111 reveals a problem: we need to have the same tests for what's allowed/sensitive in metacity's own window, that needs to be synced with how the allowed actions hint is set. The patch disables some actions that are logically possible: - shading a minimized window - maximizing a minimized or shaded window No reason to do that from a code standpoint, perhaps from a UI standpoint, but it *is* possible to maximize a window, minimize, then unminimize and it's still maximized, so it is user visible for example that a minimized window can be maximized. Or something. Anyhow, the important comment is that filling in the "ops" variable in meta_window_show_menu() needs syncing with the stuff in this hint.
Maybe set_allowed_actions_hint() should *only* be called from recalc_window_features, and do the old_* check for whether to really change the hint for the dynamic sensitive/insensitive checks as well? Then you just have one function and you avoid the X server traffic whenever possible.
See also bug 90420.
*** Bug 314892 has been marked as a duplicate of this bug. ***
Bug 314892 suggests the possibility of making the actions work (meaning to unminimize and then do the action for the window?) rather than disabling them in the menu.
It's only consistent. After all, you can minimise a maximised window, so why not be able to maximise a minimised window? And as I mention in the other bug, that's what other window managers do (and KDE as well)
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.