GNOME Bugzilla – Bug 360900
xterm -iconic does not start iconized
Last modified: 2007-12-13 03:25:59 UTC
xterm -iconic does not start iconized. This is a regression caused by the fix for bug #334899.
Right, so the problem was that in bug 334899 we were only supposed to unminimize transients of a new window that was going to be shown, instead we unminimized all the transients AND the window itself unconditionally. A condition was later added, but it turns out to just be a hack for when restarting. Also, the meta_window_foreach_transient() call just above that area of the code looks like it can be nuked as well. Should be easy to fix.
Should I hack on this, or is it a gnome-love candidate?
We could make it into a gnome-love candidate with a better description, but I'm too lazy to do that right now. Go for it. :-)
*** Bug 375713 has been marked as a duplicate of this bug. ***
*** Bug 440691 has been marked as a duplicate of this bug. ***
*** Bug 450055 has been marked as a duplicate of this bug. ***
This is biting lots of people, and it's definitely not just xterm. Hints about the fix, again, are in comment 1.
It's been six months and no gnome-love action, so I'll fix this myself.
As it is noted in bug 440691, the IconicState initial state is not honored if set with XSetWMHints(). I experimented a bit more and figured out one more issue: If one invokes the XSetWMHints() function, sets the initial_state to WithdrawnState using the StateHint flags, and then maps the window (via the XMapWindow() function), Metacity displays the window. It means that Metacity completely ignores the initial_state value and alsways displays windows in NormalState initially. The version of Metacity I played with is 2.16.1.
(In reply to comment #9) Well, after some more experiments I noticed that KWin ignores the inital_state of WithdrawnState either. And I feel this is a correct behavior. Because it's hard to imagine why one would ever want to call the XMapWindow() and leave the window unmapped. Though I wonder what is the meanning of the initial_state == WithdrawnState in this case? Is it just supposed to be ignored (what we see in practice)? Where is this stated?
The ICCCM state transition rules create an invariant that a withdrawn window is always unmapped. Mapping a window and asking for it to be in WithdrawnState does not make sense (if someone wanted to do that, probably what they really want is an override redirect window). The only time the WithdrawnState value might be used by the WM is that the WM can set WM_STATE to WithdrawnState when a window is withdrawn, or alternatively the WM is allowed to just remove the WM_STATE property for withdrawn windows. Otherwise, WithdrawnState is only of interest to clients, since the WM "forgets" about withdrawn windows and only cares about windows when they are not in WithdrawnState.
"xterm -iconic" works as expected for me with metacity2.20 on Fedora8 box.
Yeah, Owen fixed this; it was a one liner. *** This bug has been marked as a duplicate of 491090 ***