Re: Pending 1.2 stuff

[Matthias Clasen <maclas gmx de>]

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

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

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

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

Matthias 

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net