comments on current spec

[John Harper <john dcs warwick ac uk>]

Hi,

I was stuck at home this morning, so I thought I'd take a first pass at
implementing the current state of the spec, for sawmill (or whatever
it's called these days)

I found a number of things that only became apparent to me once I'd
started implementing it, so I thought I'd share them. If they were
covered earlier, or I missed something, please tell me to shut up..

_NET_CLIENT_LIST[_STACKING]

	should this only include currently mapped windows?

	type is XA_WINDOW, shouldn't this just be WINDOW?

_NET_ACTIVE_WINDOW

	repeated sentence in description

	doesn't specify what to set it to if _no_ window is focused

	should the client message also select the desktop/viewport the
	window is a member of?

_NET_CLOSE_WINDOW / _NET_WM_MOVERESIZE

	why the inconsistent names?

	I suggest _NET_WM_CLOSE_WINDOW / _NET_WM_MOVE_RESIZE, or
	_NET_CLOSE_WINDOW, _NET_MOVE_RESIZE (see later)

	also, why not have separate messages for move and resize, there
	seems to be nothing gained from combining them?

	also, if allowing resize grab position to be specified why not
	add the possibility to restrict the movement to a single
	dimension?

_NET_{INSERT,DELETE}_DESKTOP, _NET_DESKTOP_VIEWPORT

	format of these client messages is never specified, I assumed:

	INSERT:	format = 32, data[0] = workspace to insert before

	DELETE: format = 32, data[0] = workspace to delete

	VIEWPORT: format = 32, data[0] = x in pixels, data[1] = y in pixels

same for _NET_DESKTOP_GEOMETRY

	I assumed: format = 32, data[0] = width in pixels, data[1] =
	height in pixels

	[ actually I didn't implement this since it conflicts with user
	settings ]

_NET_PROPERTIES

	do we really need it, is there enough measurable benefit to
	warrant this thing?

_NET_WM_DESKTOP

	the 0xfffffff thing means to me `put it on desktop 2^32-1', not
	`put it on all desktops'. Why not just add another STICKY-like
	state instead?

_NET_WM_STATE client message

	allows two actions specifically to allow simultaneous
	vert/horiz maximization; why not just define a `pseudo state'
	_NET_WM_STATE_MAXIMIZED that signifies this?

general:

	Some GNOME apps (the tasklist) assume that the _WIN_AREA
	property will be set on all client windows (even though it's
	not in the spec). This isn't in the new spec either -- might
	this be a problem for these apps or are they just broken?

I couldn't quite see the logic to the use of _WM_ in atom names? Is
there one? Since this is the wm-spec, why not assume the WM? Or are
there going to be other _NET_ prefixed specs?

if anyone's interested, my implementation is at:

	http://www.dcs.warwick.ac.uk/~john/wm-spec.jl

though it's only about 80% complete and totally untested,

	John