Re: Pending 1.2 stuff

[Lubos Lunak <l lunak sh cvut cz>]

On Thursday 22 August 2002 11:17, Matthias Clasen wrote:
> > > 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?
>
> Its not that simple. "Stacking order" is a relation between all windows.
> Things I have
> in mind are stacking order policies which go beyond any fixed layering,
> e.g. use
> a layering for initial insertion of windows in the stack, but do not
> restrict the users
> ability to raise normal windows to the top of the stack, then have them
> jump back to
> their layer when the focus moves elsewhere...

 This is all the "normal" windows. I don't mind if the WM puts such windows 
upside down or whatever.
 Or if you care that much about not exactly specifying the layers, we can 
simply only suggest it. We do that already anyway (DESKTOP down below, 
"normal" windows, DOCK above).
 Your definition of FLOATING is at least insufficient from the user's point of 
view - if I say I want the window to be on top, I want it to be above the 
docks too (and now we can start discussing if it makes sense to have windows 
above active fullscreen window ;)  ). And I also fail to see where I'd need 
to keep one window only above other windows of the same type, but necessarily 
above windows of other types. Thinking of it, FLOATING probably makes sense 
only for normal windows and dialogs.

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

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

 Actually, after thinking about your way of doing it, it doesn't cover this 
case either, so it's the same.

>
> First of all, I think we need a clear set of use cases for STAYS_ON_TOP,
> which
> are not covered by the spec. I think the dialog and panel examples are not
> really
> valid. The dialog examples are about directing the users attention to a
> dialog, for which the spec recommends the urgency hint. For the panel

 Once again, I'm not insisting KDE is doing the right thing here with the 
dialogs.

> example I am tempted to say
> that "sub-normal" panels should simply have type DESKTOP (to keep the below
> normal windows ) and state FLOATING (to keep them above the "background"
> window).

 Given the very vague definition of TYPE_DESKTOP, it could be really 
interesting to try this. Some WMs would probably fall flat on their face, not 
even expecting more than one desktop window (e.g. KWin a couple of months 
back). Others would maybe try to stretch such windows to cover the whole 
screen area, or some other interesting things. And IMHO that's also breaking 
the internal consistency of the spec ;).

>
> Regarding the purpose of the spec, I think that internal consistency of the
> spec is
> at least as important as including every possible feature.

 I don't see where I'm trying to break internal consistency or include every 
possible feature.

 BTW, is it your or my mail client causing the bad wrapping of what you wrote?

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