Re: ICCCM breakage, IconicState, and desktops

[Havoc Pennington <hp redhat com>]

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
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.

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.

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

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.
 
> 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.

Havoc