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

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

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.

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.

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