questions/suggestions about changes in 1.0pre2

["Bradley T. Hughes" <bhughes trolltech com>]

I've been looking over the new "1.0pre2" spec that is on freedesktop.org,
and I thought I should ask about some of the changes that have been made
(I didn't see some of them discussed on this list)

_NET_NUMBER_OF_DESKTOPS:  when I implemented the spec, a client could
change this by sending a client message to the root window with
message_type = _NET_NUMBER_OF_DESKTOPS, but now the spec says
_NET_SET_NUMBER_OF_DESKTOPS.  This is the only root window message that
uses a different message_type from the property itself.  I think this
should be changed back to the original.

_NET_DESKTOP_GEOMERTY:  <pedantic> The type should probably be
CARDINAL[][2]/32 (same as _NET_DESKTOP_VIEWPORT) instead of just saying
CARDINAL[2]/32... extra clarity</pedantic>

_NET_WM_VISIBLE_NAME_STRING:  The _STRING should be dropped off the end,
to keep consistent naming (WM_NAME, _NET_WM_NAME,
_NET_WM_VISIBLE_NAME).  My implementation uses _NET_WM_VISIBLE_NAME.

_NET_WM_WINDOW_TYPE:  I think the _NET_WM_WINDOW_TYPE_TOOLBAR type should
be simply _NET_WM_WINDOW_TYPE_TOOL.  Floating toolbars should still use
this type, but it causes less confusion for windows that aren't toolbars,
but which should be drawn with less decorations (a small color grid for a
painting program probably shouldn't have full decorations/menus
etc... just a small titlebar and a close button probably)

_NET_WM_STATE: I think this should be a bitfield.  We are assuming that
all state value are boolean flags (since we have set/unset/toggle
commands).  As extensions are made and things added, this will become
quite a large property for storing nothing but boolean flags.  I suggest
this:

	_NET_WM_STATE, CARDINAL/32
	Modal        = 1<<0
	MaxVert      = 1<<1
	MaxHoriz     = 1<<2
	Shaded       = 1<<3

Note that the state information has been trimmed down to include only
useful state information (common UI elements).  These are simply hints

The argument made against StaysOnTop also holds true for Sticky and
SkipTaskbar.  These hints/states dictate policy, which should be done
"through the window manager configuration".  If a particular
implementation wants to use Sticky, SkipTaskbar or StaysOnTop, it should
be done outside the _NET namespace (as I have been told *many* times).

This is the part where people get pissed off.  Some feel that Sticky and
SkipTaskbar are essential hints for working with the desktop.  If enough
people Sticky and SkipTaskbar, then I feel that StaysOnTop should also be
included.  Either we include nothing in the spec that describes policy
(like Sticky, StaysOnTop and SkipTaskbar do) or we include all reasonable
policy.

Give me one good reason that Sticky or SkipTaskbar should be included but
StaysOnTop should not.  One dictates fixed position in the x/y
coordinates, the other fixed position in the z coordinate.

 --
Bradley T. Hughes <bhughes trolltech com>
Waldemar Thranes gt. 98B N-0175 Oslo, Norway
Office: +47 21 60 48 92
Mobile: +47 92 01 97 81