Re: Proposal: _NET_WM_STATE_MINIMIZED

[Lubos Lunak <l lunak suse cz>]

On Thursday 17 of June 2004 01:21, Havoc Pennington wrote:
> On Wed, 2004-06-16 at 13:31, Elijah P Newren wrote:
> > Well, as I said above, it looks like we can chuck my proposal.  However,
> > it'd still be really nice to have some clarification.  I read through
> > the thread and couldn't see any conclusion reached.  What I did find was
> > that it appears Sasha equates IconicState with minimized and that he
> > defines shaded as a subset of NormalState
> > (http://mail.gnome.org/archives/wm-spec-list/2001-December/msg00007.html)
> >, yet the Metacity implementation definitely doesn't do that (it does
> > IconicState == minimized || shaded).  And you pointed out in that thread
> > that the ICCCM didn't equate the IconicState and minimized and that the
> > ICCCM defined IconicState to be ambiguous. 
> > (http://mail.gnome.org/archives/wm-spec-list/2001-December/msg00020.html)
>
> I think the conclusion is in the spec, though it might be worth adding
> an explicit "why not STATE_MINIMIZED?" kind of note.
>
> Other than the definition of HIDDEN, there's this paragraph on
> implementing workspaces:
> http://freedesktop.org/Standards/wm-spec/index.html#id2766647
>
>         The second option is to keep all managed windows as children of
>         the root window and unmap the frames of those which are not on
>         the current desktop. Unmapped windows should be placed in
>         IconicState, according to the ICCCM. Windows which are actually
>         iconified or minimized should have the _NET_WM_STATE_HIDDEN
>         property set, to communicate to pagers that the window should
>         not be represented as "onscreen."
>
> So that basically implies that we decided IconicState != minimized, i.e.
> we kept the strict ICCCM interpretation.
>
> We could probably add something to the "Implementation notes" at the end
> where we have the other ICCCM clarifications e.g. on window gravity. Not
> sure what the exact wording would be.

 I personally think the simplest solution would be dumping all this mess and 
starting over from scratch. And the current state is a mess. The meaning of 
STATE_MINIMIZED would be simple - a minimized window is a window explicitly 
hidden by the user (to taskbar, desktop icon, wherever). Can anybody tell me 
how to currently represent this state 
(http://bugs.kde.org/show_bug.cgi?id=81271)? Because I don't know.

 The current state is a result of three iterations:
- 1. ICCCM - no concept of virtual desktops, shading or whatever, so everybody 
assumes iconic==minimized. Qt's QWidget::isMinimized() works that way, and 
I'm quite sure basically work and think the same way.
- 2. pre-EWMH and early EWMH until STATE_HIDDEN - usage of the iconic WM_STATE 
is "random" - since apps mostly assume iconic==minimized, things like virtual 
desktops or shading keep the window in normal state, despite what ICCCM says
- 3. current EWMH - somebody notices 2. is an ICCCM violation, and after that 
refered thread STATE_HIDDEN gets added (and, if you ask me, that was a bad 
decision).

 So, if I understand the current state, it's like this:
- "normal" window on current desktop - WM_STATE is NormalState, nothing else 
is set
- "normal" window on inactive desktop - WM_STATE can be both, depending on the 
implementation, nothing else set
- shaded window - WM_STATE is Iconic, STATE_HIDDEN, STATE_SHADED
- minimized window - WM_STATE is Iconic, STATE_HIDDEN, nothing else
- inactive window in a group of tabbed windows - it's probably the same like 
with virtual desktops
- and let's not forget the case of apps written before the introduction of 
STATE_HIDDEN

 Which means
- iconic != minimized
- there's no good way how to recognize the minimized state (see the KDE bug)
- the iconic state itself probably doesn't make much sense, as it doesn't have 
any clear meaning, or even something close - you can e.g. have a window in 
NormalState that's not actually visible because it's on inactive virtual 
desktop with WM that doesn't unmap in such case, and only its iconic 
representation (=taskbar entry) is visible. Moreover one can in practice 
achieve the same with simply obscuring the window by another one, so I kind 
of fail to see the point of the iconic state[*].

 I personally think it'd be the simplest if we introduced STATE_MINIMIZED 
simply for telling the taskbar about the window's state, and stated it's not 
the app's bussiness to know if it's minimized or not (it can use 
VisibilityNotify to find out if it's visible).

[*] - I'd like also to point out that for KDE3.2 I tried to make use of the 
*_ICON_NAME properties when windows are in the iconic state, with eventually 
coming to the conclusion that it's simpler to forget something like that 
exists. Apparently I'm not the only one who doesn't quite comprehend what it 
is good for or how exactly it should be used.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/