Re: ICCCM breakage, IconicState, and desktops

[Sasha Vasko <sasha aftercode net>]

On Wednesday 05 December 2001 02:29, Matthias Clasen wrote:
> > To avoid that you should start displaying WM_ICON_NAME, despite the fact
> > that window was not really minimized, but merelly moved off-desktop.
> > Essentially you have to display window as minimized, even thou 
> > _NET_WM_MINIMIZED is not
> > set. What is the value of _NET_WM_MINIMIZED in such context let me ask
> > you ?
> > None whatsoever.
>
> Whats wrong with pagers/taskbars using WM_ICON_NAME instead of WM_NAME if
> the
> window is in IconicState ?  But even if they do so, there is one crucial
> difference between
> IconicState + _NET_WM_MINIMIZED and IconicState - _NET_WM_MINIMIZED
>
> IconicState + _NET_WM_MINIMIZED:
>     pagers/taskbars display WM_ICON_NAME, pagers don't represent the main
> window
> IconicState - _NET_WM_MINIMIZED:
>     pagers/taskbars display WM_NAME, pagers represent the main window,
> *even though it is unmapped*

doh, you represent main window, yet you name it with WM_ICON_NAME. 
Sounds wierd.

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.

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.

> > Now what is the exact semantics of this new state, nobody was able to
> > tell exactly so far. My perseption is that it is almost identical to what
> > IconicState was considered to be. And IMHO introduction of this state
> > will cause nothing but confusion among application developers, with
> > something
>
> like
>
> > the following occuiring in their monds :
>
> Application developers should not worry about wm state transitions at all.
> This is the job of the wm.

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.

LIkewise client may request to be iconified after some period of inactivity.

> Matthias

Sasha.