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

[Sasha_Vasko osca state mo us]

> On Fri, 22 Sep 2000, Julian Adams wrote:
> 
> > > >
> > > > A change to the protocol itself would not be binary incompatible 
unless you
> > > > alter the public class interface. That isn't required is it ?
> > >
> > > The change in the protocol would require a change in the public
> > > interface.  I tried to keep the classes independant of KDE (so that 
they
> > > could be used in other projects), and in doing so I would have to 
expose
> > > this list of window types to the application.  So instead of a 
simple
> > >
> > > WindowType NETWinInfo::type() const;    method I would now have to 
do
> > > something like:
> > >
> > > Array NETWinInfo::types() const;        which completely changes the 
semantics
> > > of the class.
> >
> > This isn't really what I meant. I wasn't considering a list of
> > alternative, just a mechanism so that a non extended conforming
> > implementation could detect an extension value (atom), and ignore it
> > (defaulting to something mandated in the spec).
> > 
> This is something that could be done, yes.  But this seems counter
> productive.  "Sure... the spec allows for easy extensibility, and my 
code
> implemenets the spec, you just can't extend it easily"

You are terribly wrong. What extensibility means that you can implement 
needed extensions inside any particular environment ( say KDE for example 
)
that will not break any other environments.
For example if you use list of atoms - you can implement StaysOnTop as 
additional 
atom - all the KDE applications will be able to use it, but at the same 
time 
everybody else - who does not like it - will simply ignore it and keep 
using 
fallback standard values ( listed in the same array ).

By choosing to use single value for the property - you restricting 
everything 
( including yourself ) without need.

> > This protocol change could be covered without changing the existing
> > interface.
> >
> > >
> > > Again, I really don't see the point in the list.  If someone is 
going to
> > > try and extend the spec, they should not (IMO) reuse the _NET 
properties
> > > to do so.
> >
> > I'd be quite happy to explicitly disallow extensions which are in any
> > way visible to conforming implementations at the protocol level. i.e.
> > don't go anywhere near the atoms / values specified in the spec.
> >
> > In that case I wouldn't mind using enums.
> >
> > But you (Bradley) are extending the spec - to _NET_WM_STATE you're
> > adding:
> >
> > <from Bradley's previous mail 12/06/00>
> > >        And we added a StaysOnTop (i.e. AlwaysOnTop, OmniPresent, 
...)
> > >        StaysOnTop      = 1 << 6
> > <end>
> >
> > lots of people vehemently did not want this added.
> 
> Yes... I remember this.  As much as I hate to sound stubborn, regardless
> of what this list says, the StaysOnTop hint is going to stay in my
> implementation of the spec.  I run KDE and Blackbox both, and I don't 
see
> the point in configuring applications *twice* for the same effect. :)

Dude, If you have _NET_WM_STATE as a list of atoms - you can add
STAYS_ON_TOP atom and mention it in the list. KDE and Blackbox will use it 
- 
everybody else will ignore it - everybody will be happy.
The same thing may happen if you use a bit combination ( as shown above ),
but if somebody else implement some other extension using the same bit - 
KDE and Blackbox will be confused. Adding StaysOnTop to specs will not 
help,
as it is a simple example and there could be hundreds of other extensions 
like this one. You can't possibly add them all to the spec, yet you don't 
want 
to restrict people from implementing those.

> 
> > It would seem that either:
> > 1) StaysOnTop as is should be dropped as an illegal extension
> > implementation, we could use enums, and write in a "do not use other
> > values" clause (KDE could implement StaysOnTop under the existing
> > interface, away from the core of the spec, any way it wanted)
> > 2) Use atoms, and allow explicitly allow extensions, with these ignored
> > by non supporting implementations.
> > 3) Add StaysOnTop to the spec (already hotly debated and not popular)
> >
> > I'd be happy with 1) or 2) and either should allow binary compatibility
> > to be maintained. Would that be too large a price to pay for
> > interoperating taskbars and wms ?
> 
> I vote for #3 :)

With the approach #3 you'll have to setup a standard body that will be 
registering all the possible extensions and adding them to the specs.
At the same time approach #2 you don't have this need, yet anybody can 
implement any extension without confusing everybody else, and that 
includes
you being able to implement StaysOnTop localy to your environment.

As I have said before change from bitfield to atom list in your 
implementation
will take like 20 lines of code (to convert list into bit combination), 
10 minutes of your time, absolutely  ZERO impact on linked application.
At the same time you gain greater flexibility and extensibility, from 
which you 
can immidiately benefit by implementing non standard extension of 
StaysOnTop.

Prove me wrong.

> 
> > >
> > > If some window happens to be a rotating dialog with spinning 
titlebars,
> > > then that should be set in a property other than _NET_WINDOW_TYPE. I 
have
> > > considered _NET_WINDOW_TYPE as standard types.
> > >
> > > > Julian
> > > >
> > > >
> > >
> > > --
> > > Bradley T. Hughes <bhughes trolltech com>
> Bradley T. Hughes <bhughes trolltech com>

Cheers
Sasha Vasko