Re: Pending 1.2 stuff
- From: Lubos Lunak <l lunak sh cvut cz>
- To: wm-spec-list gnome org
- Subject: Re: Pending 1.2 stuff
- Date: Wed, 21 Aug 2002 12:09:55 +0200
On Wednesday 21 August 2002 01:48, Havoc Pennington wrote:
> Lubos Lunak <l lunak sh cvut cz> writes:
> > Sorry, I know I'm a bit late, but I don't think this definition of
> > STAY^H^H^H^HFLOATING is very good. It IMHO shouldn't just say 'above
> > windows of the same type'. What if I e.g. want to have a normal window
> > above (part of) dock window? With the current definition, I most probably
> > just don't have any chance to do it. What would be the problem with using
> > something like I suggested here
> > http://mail.gnome.org/archives/wm-spec-list/2002-June/msg00016.html
> > ?
>
> So I think you may be right; what we were originally saying is that
> _FLOATING would be "the kind of window xmms and gkrellm are," and in
> that case we could just leave it up to the WM to establish how such a
> window relates to dock windows and other kinds of window.
>
> There is one other possible use of "on top" I've seen, which is for
> dialogs that you might want to keep on top for some reason; one case
> of this is say the ssh-add password dialog on login, maybe you want to
> keep that above other apps that start up on login.
>
> I don't _particularly_ want to mix this with the xmms/gkrellm case as
> they may really belong in different layers.
>
> I think KDE uses STAYS_ON_TOP in more of these general-purpose cases -
> could you maybe grep the source code and generate a list of
> STAYS_ON_TOP uses in KDE?
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).
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.).
> > Havoc: Yes, sorry. Any special reason why the list doesn't change
> > Reply-To: to point to the ML?
>
> Well that's a very controversial topic. ;-) Haven't you ever seen a
> "should lists set Reply-To" neverending thread? It's a classic right
> up there with "emacs vs. vi"
Well, all KDE MLs have this, so let's see how long you can stand me
forgetting to change it here >;).
--
Lubos Lunak
developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: llunak 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/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]