Re: Pending 1.2 stuff

>  Actually, KDE uses STAYS_ON_TOP even for things like the panel (it's 
> to configure the panel not to be above normal windows). We also use it 
> few dialogs, like the minicli or the 'do you accept the cookie' dialog 
> specific one maybe shouldn't actually use it). And of course 'Always On 
> is one entry in the window operations menu, so people turn it on for 
> windows they want (e.g. a video player).

These sounds all all wrong except for the explicit user action. Making 
sure that
dialogs catch the users attention should be done with the urgency hint. 

> Maybe we should simply in the spec explicitly state the layering order. 
> now, KDE has windows stacked this way, from the bottom:
> - "normal windows"
> - STAYS_ON_TOP windows
> - fullscreen window if it has the focus
>  Transient windows are (or at least should be) placed above the windows 
> they're transient to.
> For example, we could make the layering order this way (from bottom):
> - "normal" windows (i.e. not elsewhere)
> - TYPE_SPLASH, (TYPE_MENU?), TYPE_DOCK(only if we have also STAYS_BELOW)
> - TYPE_FULLSCREEN, if focused (otherwise as "normal")
>  And transient windows will be kept above their windows (this will take 
> of toolbars, etc.).

No, lets not go back to explicit layers. No fixed layering order will do 
(as you 
already acknowledge for fullscreen - which is a state, not a type, btw) 
and the
spec should leave enough room for implementing clever stacking order 

And I'm almost sure that once we've accepted your order, someone will 
complain that
he needs a STATE_STAYS_OVER_THE_TOP for windows which shouldn't even be 
covered by
focused fullscreen windows. 

Finally, the current wording for STATE_FLOATING doesn't rule out to 
implement it
in the same way as the KDE STAYS_ON_TOP hint - we only say that it should 
be kept on 
top of windows of the same type, not that it should stay below windows of 
any other



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