Re: ICCCM breakage, IconicState, and desktops

[Sasha Vasko <sasha aftercode net>]

On Thursday 06 December 2001 01:06, Havoc Pennington wrote:
> Sasha Vasko <sasha aftercode net> writes:
> > What is exact definition of this new "minimized" state ? If all you want
> > is to hide window from the Pager then you really want HIDDEN state. For
> > that we already have _NET_WM_STATE_SKIP_PAGER/TASKBAR.
> >
> > That actually creates interesting question that may be SKIP_PAGER/TASKBAR
> > should be moved into _NET_WM_TYPE, and instead _NET_WM_STATE_HIDDEN
> > should be added. Thats separate discussion though.
>
> This is a possible alternative to a MINIMIZED hint.
> You raise an interesting issue - are SKIP_PAGER/SKIP_TASKLIST supposed
> to be set by the window manager or the app? I always assumed they were

Well, these two differ from others in the fact that they normally are not 
changed during entire lifetime of the client window. It normally is set by 
window manager, based on app request or its own config, when window is 
initially mapped, and remains unchanged untill it gets destroyed. I can 
hardly envision user turning it on/off while window is on screen. Therefore 
those are not really states, if you define state as something that is 
volitile and changes during the lifetime of the window. From the other hand 
we defined WINDOW_TYPEs using purpose of the window as the base, and 
SKIP_PAGER hardly seems to be a purpose.

> for apps to control. What do most current window managers assume?
> Do any current window managers e.g. set SKIP_PAGER when they minimize
> an app?
>
> If SKIP_PAGER is being treated as a message from window manager to
> pager, then yes it solves our problem - we can specify that pagers
> should display all windows that are not SKIP_PAGER, even if the
> windows are in IconicState.
>
> If SKIP_PAGER isn't that, we could add _HIDDEN which is such a message
> from WM to pager.

Adding _HIDDEN is a good alternative. It has clear meaning, and does not 
conflicts with anything else. Actually it would be a good addition regardless 
of the problem in question.

Perhaps explanation like that : 
<quote>
When _NET_WM_STATE_HIDDEN is set, Pager should hide window from its desktop 
representation, regardless of whether client window is in Iconic or 
NormalState.
Otherwise :
When client is in NormalState - it should be shown by the Pager
When client is in IconicState and its Icon window as specified by WM_STATE 
property is mapped, then Pager should display its icon window (if any).
When client is in IconicState and neither of its windows are mapped Pager 
should display Clients normal window, yet Pager should use 
WM_ICON_NAME/_NET_WM_ICON_NAME as client's title (if any).
</quote>

Important difference between SKIP_PAGER and HIDDEN is that SKIP_PAGER 
typically remains unchanged throughtout entire lifecycle of the window, while 
_HIDDEN could be set/unset by window manager on a temporary basis. At the 
same time it allows taskbar/windowlist app to display _HIDDEN window 
differently.

It actually provides additional benefit of more closely specifying expected 
behaviour - that you want to hide minimized/iconified windows from the Pager. 
That is important, since Pager may attempt  to display client's icon window 
otherwise ( both fvwm and AfterStep Pagers do that for example )

> Hmm, even the current spec needs some clarification here. I'm guessing
> we should just do whatever KDE is doing in their current implementation.
>
> > Really try and define what exactly "minimized" state is, and you'll see
> > that it either indistiguishable from ICCCM defined IconicState, or
> > requires additional information to be meaningfull.
>
> The MINIMIZED state would mean the window is minimized - that's it.

minimized could be many different things, depending on window manager 
It could be: a)smaller version of titlebar, b)smallest possible size of the 
normal window, c) icon window, etc. And in some of this cases you would not 
really want to hide the window.

> IconicState means the window is unmapped as spec'd in the ICCCM -
> that's it.

It also means that if application's title is displayed, then _WM_ICON_NAME 
should be used over WM_NAME, and if some window is mapped then it could only 
be icon window. That narows it down considerably.

> By convention, when apps request a transition to/from IconicState, we
> would assume they meant to minimize/unminimize themselves, assuming
> they are currently minimized; if they weren't minimized but
> IconicState for some other reason, the WM would ignore them, or
> whatever makes sense for that WM to do.

right.

> > Both IconicState<->NormalState transition and _NET_WM_STATE
> > transitions could be requested by client using ClientMessage. For
> > example e-mail client can attempt to deiconify self when new mail
> > arrives. I can just imagine it requesting deiconification when in
> > fact it was simply moved off-desktop, and it should have instead
> > requested wm to move it onto active desktop.
>
> Remember that clients don't deal with all this hints stuff directly;
> they are going via toolkits. We can just get it all right in the
> toolkit, as long as we agree on this list what constitutes "right."
>
> We have a function in GTK called gtk_window_present() which
> deiconifies, raises, moves to current desktop, all that stuff; usually
> this is the thing an app would call in the situation you describe.  We
> can also check if the WM supports a hint such as
> _NET_WM_STATE_MINIMIZED, and behave differently according to that
> check.

Next thing you know is some newcomer comes up and develops kick ass toolkit 
that interprets things differently. Its better to leave as little space as 
possible for such misinterpretation.

>
> Havoc

Sasha