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

[John Harper <john dcs warwick ac uk>]

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?

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