Re: Pending 1.2 stuff
- From: "Matthias Clasen" <Matthias Clasen poet de>
- To: Lubos Lunak <l lunak sh cvut cz>
- Cc: wm-spec-list gnome org
- Subject: Re: Pending 1.2 stuff
- Date: Wed, 21 Aug 2002 12:39:06 +0200
> Actually, KDE uses STAYS_ON_TOP even for things like the panel (it's
possible
> to configure the panel not to be above normal windows). We also use it
for
> few dialogs, like the minicli or the 'do you accept the cookie' dialog
(this
> specific one maybe shouldn't actually use it). And of course 'Always On
Top'
> is one entry in the window operations menu, so people turn it on for
some
> 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.
Right
> now, KDE has windows stacked this way, from the bottom:
> - TYPE_DESKTOP
> - "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):
> - TYPE_DESKTOP
> - STATE_STAYS_BELOW?
> - "normal" windows (i.e. not elsewhere)
> - TYPE_SPLASH, (TYPE_MENU?), TYPE_DOCK(only if we have also STAYS_BELOW)
> - STATE_STAYS_ON_TOP
> - TYPE_FULLSCREEN, if focused (otherwise as "normal")
> And transient windows will be kept above their windows (this will take
care
> 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
policies.
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
type.
Matthias
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]