Re: STATE_FLOATING (was Re: Pending 1.2 stuff)



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

Good. The implementation notes on "Urgency" probably need to be expanded a 
bit.

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

Something like this, yes.

On the nitpicking side, I think that the names of the states would perhaps 
be nicer as _NET_WM_STATE_ABOVE / _NET_WM_STATE_BELOW or 
_NET_WM_STATE_RAISED / _NET_WM_STATE_LOWERED or _NET_WM_STATE_FLOATING / 
_NET_WM_STATE_SUNKEN.

Matthias



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]