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

[Sasha_Vasko osca state mo us]

> On Thu, 21 Sep 2000, Julian Adams wrote:
> 
> > > On Thu, 21 Sep 2000 Sasha_Vasko osca state mo us wrote:
> > >
> > > > >On Thu, 21 Sep 2000, John Harper wrote:
> > > > >
> > > > >> Bradley T. Hughes writes:
> > > > >> |> I think the differences were in _NET_WM_WINDOW_TYPE and 
another
> > > similar
> > > >> |> property (spec defines these as vectors of atoms, KDE
> > implementation
> > > > >> |> has them as integers). A few days ago someone tried sawfish 
with
> > the
> > > > >> |> KDE2 beta and ran into problems due to this (sawfish 
includes a
> > > > >> |> prototype implementation of the current spec)
> > > > >> |
> > > > >> |and as i recall... this was discussed but never resolved... 
perhaps
> > > > now is
> > > > >> |the time
> > > > >>
> > > > >> Definitely -- is there any possibility that you will change 
your
> > > > >> implementation to match the current state of the spec?
> > > > >
> > > > >Well... a binary incompatible change to KDE2 just before a 
release
> > would
> > > > >upset quite a few people.  A very good, convincing argument over 
why a
> > > > >list of atoms is more desirable than an enumerated value would 
have to
> > be
> > > > >presented.  The argument that the list can be extended in the 
future
> > also
> > > >
> >
> > 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.

Nope, not necessarily.

If KDE apps are build to use type() that returns single type of window - 
then
there is no sense whatsoever to return array to them - they have no use 
for it.
Simply perform preprocessing of the property data INSIDE the type() - and 
choose
single type to return ( like the first supported atom for example ). 

In addition, later on you can add one more interface - like :
Array NETWinInfo::all_types() const;
to provide bonus functionality for those who may decide to use it.
I seriously doubt thou that any app may need this. If you implement 
fair logic inside type() interface to make sane choice - 99% of the apps
should be fine with it. Now, to MAKE this sane choice - you could use 
fallback 
technique actually utilizing the fact that property contains list of 
atoms.

Please understand that there is no guarantee that apps outside of the KDE 
will
use exactly the same set of atoms to identify its type, so by the way of 
allowing them to use several - like one standard and one extended - you 
shield
yourself from problems, and proactively implement support for more 
applications, 
without any costs to yourself. You actually gain, without sacrificing 
anything.

As a side note, I'd like to point out that, bitwise OR of flags is much 
better way
to store set of predefined values, then an array. Passing array around is 
like 
driving tank in downtown.

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

The problem is that those ppl may not know that your opinion exists, 
besides
why would you want to force additions of yet more properties, when you can 

allow ppl to reuse whats already there, without - again - sacrificing 
anything.

It does not really matter for me, as a window manager developer, which way 

you go - single atom is merely a subset of array functionality, both ways
stricly saying are comforming to existing specs. But by choosing to use 
just
a single atom in your implementation - you stoomp on your own feet, and 
cut 
yourself short of additional safety precautions.

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

Cheers
Sasha Vasko