comments on current spec


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


	should this only include currently mapped windows?

	type is XA_WINDOW, shouldn't this just be 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?


	why the inconsistent names?


	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


	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


	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 ]


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


	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?


	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:

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]