Re: ICCCM breakage, IconicState, and desktops

[Olivier Chapuis <olivier chapuis free fr>]

On Sat, Dec 01, 2001 at 12:33:15PM -0600, Sasha Vasko wrote:
> On Saturday 01 December 2001, Oliver Chapius wrote:
> > On Tue, Jun 12, 2001 at 10:47:54PM -0400, Havoc Pennington wrote:
> > > > John Harper <jsh eazel com> writes:
> > > > > > I did actually try this way of implementng multiple desktops in > 
> sawfish
> > > > (to try to be ICCCM compliant). The main problem was that pagers and
> > > > tasklist applets would display all off-desktop windows as iconified!
> > > > (e.g. not display them at all)
> > > > > > So, in the end I decided to just unmap both frame and client windows
> > > > for these windows..
> > > > > > That's easily solved by _NET_WM_STATE_MINIMIZED though, right?
> > >
> 
> Hmm, I dont remember seeing that message and I could not find it in archives.
> So I can't really see what it is referring to - implementation with virtual 
> roots ? or without ? I take it that talks about no-virtual-root 
> implementation, and bioth frame and window were unmapped when desktop becomes 
> inactive. In which case you should se window as iconic. That effect is 
> exactly why no-virtual-root-per-desktop implementation should not be used.
> Still I don't quite understand what is the question.
>

This is the point I am not agree with you. There is some wm which
use  "no-virtual-root-per-desktop" implementation for virtual
desktop for good reasons.

> > 
> > Yes,
> > This allows a window manager that does not use multiple virtual
> > roots for virtual desktops to be both ICCCM and wm-spec compliant.
> > I do not understand Sasha arguments against this _net_wm_state.
> > Sasha, it seems that your argument is: as my wm use "virtual roots"
> > for desktops we do not need this hint.
> > The fact is that
> > (i) IconicState does not mean iconic for the wm (ICCCM)
> 
> How is that ? IconicState is set by window manager, and application should 
> track changes in WM_STATE property to know what window it should animate.
> It's perfectly good and standard way used for ages to distionguish between 
> two major window states used for ages, and there is no reason whatsoever to 
> override it with another _NET_WM_STATE property. If somebody does indeed
> go the way of virtual desktops without virtual roots, then the only choice 
> they have is to be slightly ICCCM uncompliant and unmap only frame window,
> but not the client. Yes its illigal according to ICCCM. But in practice you 
> should not see any major problem with that, and its definately a better 
> solution then adding proposed property to _NET_WM_STATE. One ought to use 
> virtual roots when implementing virtual desktops. 
> 

So, you are agree that some window manager are forced to break the ICCCM.
Yes, this may cause no major problem but we my lose a "feature" here.
Also, IMHO a spec should not go into things like "this is not consistent
but this works".

> The only reason _NET_WM_STATE is there is only to compliment the 3 ICCCM 
> state, and allow for things like maximized and shaded, which is not covered 
> by ICCCM. But those states merely go as finer grain of NormalState. Non of it 
> overrides WM_STATE. And that is good, and that is how it should stay IMO. 
> Remeber - we don't override ICCCM - we complimnent it.
>

_NET_WM_MINIMIZED does not override the ICCCM. As the meaning of IconicState
is not so clear, _NET_WM_MINIMIZED (maybe _NET_WM_ICONIFIED is a better name)
"compliment" the ICCCM spec by saying when a window is really iconified
for the window manager. So this _NET state is as the other one: it gives
a "finer grain" of IconicState.

> > (ii) the only way a pager/taskbar can know if a window is iconified
> > is to use the window State.
> 
> Yep. tracking WM_STATE property is a good way to go.
> 
>

No for me, as IconicState does not neceserlly means iconic for the
wm.
 
> > So, IMHO the wm-spec intentionally break the ICCCM.
> > I currently implement the wm-spec inside fvwm (I've already
> > implemented it in an external way) and some developers do
> > not understand this (of course this is not an argument).
> 
> do not understand what ?
> 

They do not understand why the wm-spec intentionally break the ICCCM.

Regards, Olivier