GNOME Bugzilla – Bug 684741
Can't unminimize iconified window on first attempt
Last modified: 2012-10-12 15:10:55 UTC
Created attachment 225108 [details] [review] patch Recent GTK versions have started using _NET_WM_STATE_HIDDEN: http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=3f6592f60fd15fb353fc84600caefba3054dc892 (same thing was also applied to GTK3) This has triggered a metacity bug w.r.t. _NET_WM_STATE_HIDDEN which can be seen by running this simple test program: http://dev.laptop.org/~dsd/20120920/iconify.py The test creates a window that is iconified at the start. It appears in the gnome-panel window list, but if you click on it there, the window doesn't unmaximize. You have to click again, and then finally it appears. I reported this to the GTK+ list, but it was pointed out that openbox behaves OK here, and I have confirmed this. https://mail.gnome.org/archives/gtk-devel-list/2012-September/msg00042.html This is causing problems with Sugar's Journal: the user has to click on the icon twice for it to appear on-screen. Looking at the metacity code: The _NET_ACTIVE_WINDOW request causes the window to be unmimized then shown. However, immediately after, we end up in meta_window_constrain() which calls place_window_if_needed() which has this code: if (window->minimize_after_placement) { meta_window_minimize (window); window->minimize_after_placement = FALSE; } This flag only ever gets set in 1 place: reload_net_wm_state() else if (value->v.atom_list.atoms[i] == window->display->atom__NET_WM_STATE_HIDDEN) window->minimize_after_placement = TRUE; so now we have the link back to why _NET_WM_STATE_HIDDEN has triggered this bug. I guess the code that sets and deals with minimize_after_placement is still true in other situations (it was introduced in commit 07e4cacf14874746453c1c4818122e899bdc4159) but in this case its clearly not behaving quite right. I think the solution is to simply unset this flag when we're asked to unminimize a window. Patch attached. I can commit if this passes review.
If this also applies to Mutter (which is likely), you'd better open a bug there too. As it's more actively maintained, you will get a review quicker...
Can't reproduce this under mutter/gnome-shell.
Review of attachment 225108 [details] [review]: I think the patch is a hack. The problem at hand is caused by this: (1) minimize_after_placement is reset after placing the window (2) if a window is minimized, placement is deferred Resetting minimize_after_placement unconditionally in place_window_if_needed() should work as well, and makes more sense IMHO: diff --git a/src/core/constraints.c b/src/core/constraints.c index c28fc0d..ecf05d3 100644 --- a/src/core/constraints.c +++ b/src/core/constraints.c @@ -570,11 +570,10 @@ place_window_if_needed(MetaWindow *window, window->maximize_vertically_after_placement = FALSE; } if (window->minimize_after_placement) - { - meta_window_minimize (window); - window->minimize_after_placement = FALSE; - } + meta_window_minimize (window); } + + window->minimize_after_placement = FALSE; }
(In reply to comment #2) > Can't reproduce this under mutter/gnome-shell. Conceptually the issue applies to mutter as well, but it is not a problem in practice as placement of minimized windows is not deferred (which is necessary because minimized windows are shown in the shell's overview). It's probably still good to apply the change anyway.
Created attachment 226007 [details] [review] updated patch Thanks for your input - I agree. I've tested your approach, and it is working. Here it is as a patch.
Let's consider your comment as review then and push this ... Next week when rolling tarballs for GNOME 3.6.1, I'll do a metacity release as well to get the fix out.
Thanks!