Re: Pending 1.2 stuff

[Lubos Lunak <l lunak sh cvut cz>]

On Wednesday 21 August 2002 12:39, Matthias Clasen wrote:

 (Damn, Reply-To again :(  ).

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

 I didn't say it's the right way to do thing, it's simply the way we do it 
now.

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

 That "clever stacking order" probably doesn't make sense for anything else 
than that layer I called '"normal" windows'. Why should a WM try to do 
anything smart with stacking docks?

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

 And if it's left this way, somebody else will complain about something else.

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

 But it also doesn't rule out different ways how to implement it. Very vague 
spec is as good as no spec, because apps have to be tweaked for different 
implementations. I already thought a couple of times about replying to some 
wishlist items for KWin just saying 'we're not going to implement that in 
KWin, if you're used to this feature from WM XYZ, just use that XYZ with 
KDE', but I just can't. Try running e.g. Metacity or Sawfish with KDE and see 
how many small things don't work right. Some of them are KDE's fault, but 
others are just because different people interpreted differently some things 
in the spec. This vague definition of FLOATING is not enough for certain KDE 
purposes, so KDE can either try to implement it some way and pray, or it can 
be simply ignored. But what would be the purpose of this spec then?

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