Re: STATE_FLOATING (was Re: Pending 1.2 stuff)

["Matthias Clasen" <Matthias Clasen poet de>]

>  I suggest to use this instead:
> =====
> 
> [In 5.7.]
> 
> _NET_WM_STATE_STAYS_ON_TOP indicates that the window should be on top of 
most 
> windows (see Stacking order for details). Applications should not set 
this 
> hint if _NET_WM_WINDOW_TYPE already conveys the exact nature of the 
window.
> 
> _NET_WM_STATE_STAYS_BELOW indicates that the window should be below most 

> windows (see Stacking order for details). Applications should not set 
this 
> hint if _NET_WM_WINDOW_TYPE already conveys the exact nature of the 
window.
> [ this will solve my problem with being able to put Kicker below 
windows, and 
> I also think we also have some feature request for being able to put 
Konsole 
> below all windows and keep it there *shrug*]

These states are really only meant for direct user preferences, aren't 
they ? If so, we should probably say something in this direction, 
otherwise these new layering states will only be misused by app authors to 
bring their dialogs to top or whatever.

>  7.10. Stacking order
>
> The window manager should place windows in the following layers, from 
the 
> bottom:
> - windows of type _NET_WM_TYPE_DESKTOP
> - window having state _NET_WM_STATE_STAYS_BELOW
> - windows not belonging in any other layer (i.e. "normal" windows)
> - windows of type _NET_WM_TYPE_DOCK
> - windows having state _NET_WM_STATE_STAYS_ON_TOP
> - window having state _NET_WM_STATE_FULLSCREEN, if it has focus
>
>  Windows that are transient for another window should be kept above this 

> window.
> 
> The window manager may choose to put some windows in different stacking 
> position, for example to allow user to bring currently active window to 
the 
> top and return it back when the window looses focus.
> [That's it. Note it says 'should' and not 'must do so and will be shot 
> otherwise', so WMs are free to do whichever insane things they desire as 
long 
> as it keeps the stacking order at least somewhat sane.]

Note that the addition of these "layering states" introduce a lot of 
borderline cases which are not mentioned at all in the above list:

type desktop, state on top 
type dock, state below

I still don't really see the advantage of putting an expected layering in 
the spec. If you want this layering, just run a wm which implements it. If 
we make the spec so detailed that all wms have to behave identical to 
conform, we can just as well have only one wm. 

But maybe we should just get over it and stick something in the spec, as 
long as it is only recommended.  One thing which should maybe not be a 
recommendation, but rather a requirement is that 
desktop windows must be kept at the bottom of the stack, if type 
_NET_WM_TYPE_DESKTOP is supported.

Matthias