Re: STATE_FLOATING (was Re: Pending 1.2 stuff)

[Lubos Lunak <l lunak sh cvut cz>]

On Thursday 29 August 2002 12:36, Matthias Clasen wrote:
> >  I suggest to use this instead:
[STAYS_ON_TOP, STAYS_BELOW]
> 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.

 Yes, they are mainly meant for direct user preferences (if this includes 
things like configuring the panel to be below windows). The current usage of 
STAYS_ON_TOP in kdelibs/kdebase in code are mainly misuses that should be 
replaced by the urgency hint or by setting the window to be transient. 

 Probably it would be good to add to the description 
'_NET_WM_STATE_STAYS_ON_TOP is mainly meant for user preferences and should 
not be used by applications e.g. for their dialogs (the urgency hint should 
be used in such case).'

>
> >  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
[snip]
>
> 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

 Should we try to handle insanity in the spec too? ;)

> type dock, state below

 And this is actually intended, I even considered writing that one as 'window 
of type _NET_WM_TYPE_DOCK unless they have state _NET_WM_STATE_STAYS_BELOW'. 

 Maybe just saying '*_STATE_* flags should have higher precedence that 
*_TYPE_* ones, and TYPE_DESKTOP _must_ be at the bottom' would do.

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


 Maybe the wording should be different and use something less authoritative 
than 'should'. But if you look at the suggested stacking order, it simply 
makes sense to me, and I don't see why anybody would try do use something 
different (maybe with some small details like wanting to have a window above 
fullscreen or so). Tell me one serious example of why you'd e.g. want to put 
active fullscreen below normal windows, or to put DOCKs below DESKTOP. The 
list has 6 layers, but actually without those 2 _STATE_ layers it's what we 
have already anyway, just not explicitly stated this way.


-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/