Re: WM-SPEC - what needs to happen for release ?

[Sasha_Vasko osca state mo us]

> On Fri, 22 Sep 2000, John Harper wrote:
> 
> > Bradley T. Hughes writes:
> > |This same argument could hold true for the _NET_WM_WINDOW_TYPE
> > |property.  If making an extension to the _NET_WM_STATE property is in
> > |violation of the spec, then so is extending _NET_WM_WINDOW_TYPE. 
Which
> > |means the using the list for extensibility is pointless, because 
specific
> > |extensions are disallowed.
> >
> > But the whole point of allowing _NET_WM_WINDOW_TYPE to be a list of
> > atoms is to allow safe extension (either local extension, or adding
> > more _NET_ window types at a later date)
> >
> > obviously it's impossible to locally extend a set of flags encoded as
> > bits in an integer since you have the problem of allocating the bits
> > and avoiding clashes
> >
> > So I would argue that _NET_WM_STATE should also be a list of atoms, 
for
> > the same reasons. You could then add your local _KDE_STAYS_ON_TOP hint
> > without any problems. (isn't this how the Open Look hints work?)
> 
> Which is exactly what I intended to do.  Like I said... regardless of what
> this list says, my implementation will have StaysOnTop functionality. 
You
> seemed to indicate that this wasn't allowed.

It is not allowed unless you use list of atoms for _NET_WM_STATE as per 
spec,
and define your own atom for STAYS_ON_TOP.

> 
> > But I suspect you won't like this, so I'm not going to push it..
> 
> --
> Bradley T. Hughes <bhughes trolltech com>

Sasha Vasko