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

[Julian Adams <julian adams gmx net>]

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

one other issues was _NET_WM_STATE 

> |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?
> 
> Does anyone else have strong opinions about this?

> 
> (I prefer the list-of-atoms approach, but I'd rather get the standard
> finished than waste time arguing about this relatively minor issue)

Ditto - IMHO the list of atoms is cleaner, but it's most important to
get this finished. For _NET_WM_STATE there was a StaysOnTop added to,
which caused much objection. As it stands now the implementation takes a
value from the enumeration, which would NOT be forward compatible with
changes in the spec. (Meaning the next version of the spec may use this
value, not expecting KDE to use it, and thus be incompatible.) If a list
of atoms were used then compliant, but non-kde extended versions of the
could at least recognise the KDE extensions as unknown.

For this reason I'd advocate using the list.

I'd like to add a pretty please to all implementors. It's crucial that
anything that implements the spec implements it as it stands, and
commits to update until the 1.0 release. Bradley's code on a couple of
points does not comply to the spec. PLEASE go through it against the
spec on www.freedesktop.org and make it comply, or raise issues on this
list until the spec is fixed. 
Extensions must be kept separate. We should think of guidelines for
this. It may be ok to create new atoms (as using a prefix e.g.
_NET_MY_EXTENSION_XX is unlikely to cause namespace issues), but it
can't be OK to extend enumerations - there is no mediation to ensure
that e.g (myExtensionValue != somebodyElsesExtentionValue).

As it stands if KDE2 goes out with this implementation it won't
interoperate with another implementation which implements the current
draft. This would move from the current situation (we have multiple
specs which can co-exist, but don't help co-operation) to a worse future
(one spec with multiple incompatible variations which cause
unpredictable runtime behaviour)

"Bradley T. Hughes" wrote:
> 
> I don't recall the exact differences, but if necessary I can take some
> time in the next couple of days to put together a differences list.

That would be really good, but we need to resolve differences between
the spec and the implementations, not between different versions of the
implementations.

Again, I'm willing to edit the spec if no one else has time, but I don't
have the technical know-how to argue through the final decisions.

Thanks for listening, 

Julian