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

["Julian Adams" <julian adams gmx net>]

----- Original Message -----
From: "John Harper" <john dcs warwick ac uk>
To: "Bradley T. Hughes" <bhughes trolltech com>
Cc: "Julian Adams" <julian adams gmx net>; <wm-spec-list gnome org>
Sent: 21 September 2000 15:36
Subject: Re: WM-SPEC - what needs to happen for release ?


> Bradley T. Hughes writes:
> |Well... a binary incompatible change to KDE2 just before a release would
> |upset quite a few people.
>
> I haven't seen the API, but couldn't a compatibility function be added
> to translate from the integer representation to the list of atoms?
>
> |
> |The argument that the list can be extended in the future also holds
> |true for an enumerated value. The argument that a list lets the window
> |specify a "fallback" if the window manager doesn't support a
> |particular extension isn't a very good one either.
>
> I think the advantage is that the list-of-atoms can be extended without
> needing a central process for registering the extensions. E.g. if KDE
> has a special type of window, then it can specify an atom in its own
> namespace followed by a spec-defined type to fallback to. E.g.:
>
> [_KDE_WINDOW_TYPE_FOO_DIALOG _NET_WM_WINDOW_TYPE_DIALOG].
>
> Presumably kwin would then do something slightly special for the
> FOO_DIALOG while other wm's would just treat it like a normal dialog
> window
>
> |
> |How many extensions will there be? Who's responsible for
> |registering/adding them with/to the spec?
>
I'm assuming that there will be further versions of the spec, but that they
will be backwards compatible always.

OTOH by extensions I mean things that projects / people do that aren't in
the spec. Maybe they will be added later, maybe that's not appropriate. But
they must not interfere with correct operation of the spec, or future
versions of the spec.

Case 1
Say for example we use atoms, then as long as any extension atoms do not
start _NET, but rather use _SOMETHINGELSE then no conforming implementation
could mistake this for part of the main spec, and no future spec additions
would clash with this.

Case 2
If an enum is used and people add extension values e.g. 45 = MyWindowType
then it's quite possible that
1) two separate extensions use the 45 value to mean different things
2) a future revision of the spec defines 45 to mean something - it can't be
expected that future maintainers of the spec ask everyone if if they have
used a particular value in an undocumented extension.

Thinking about it I'm not sure that extensions should even use the same
lists as the spec. If this really is ok then a note should be added to the
spec saying so, and what an implementation should do if such an atom is
found (simplest option: ignore it).

> They can be specified locally, as required
>
> |A fallback list like this:
> |
> |dancing-window -> menu -> spinning-dock -> dialog -> toolbar -> normal
> |
> |is quite possible, and quite riduculous if you ask me.  If the window
> |manager doesn't support the specified enum, it should default to a normal
> |window.
>
> Maybe this example is ridiculous, but I think the example I gave above
> shows that this could be useful for (locally) extending the basic types
> where that would be useful
>
>
>
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>