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

[Julian Adams <julian adams gmx net>]

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

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 ?

> 
> 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>
> Waldemar Thranes gt. 98B N-0175 Oslo, Norway
> Office: +47 21 60 48 92
> Mobile: +47 92 01 97 81
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list