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

["Bradley T. Hughes" <bhughes trolltech com>]

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"

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

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

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

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