Re: 1.9d

[Tim Janik <timj gtk org>]

On Sun, 12 Dec 1999, Paul Warren wrote:

> Hiya,
> 
> 1.9d is up at http://ferret.lmh.ox.ac.uk/~pdw/wm-spec/
> 
> I'm afraid it is not quite in the state that I wanted, but I will not have
> time to work on it again for at least the next few days, and I wanted to
> get something up sooner rather than later to keep things moving.

thanks for biting the apple and doing another revision of the spec paul.
unfortunately i didn't get around to reply earlier, mostly due to me being
sick.
but anyways, here are my comments on 1.9d, i've tried to suggest better wording
in place where appropriate, to ease the next edit of the spec.



>_NET_CLIENT_LIST
>
>_NET_CLIENT_LIST, XA_WINDOW[]/32
>_NET_CLIENT_LIST_STACKING, XA_WINDOW[]/32
>
>   An array of all X Windows managed by the Window Manager. _NET_CLIENT_LIST has mapping order. _NET_CLIENT_LIST_STACKING
>   has stacking order. This property SHOULD be set and updated by the Window Manager.

it is not clear here whether the "SHOULD" applies to
_NET_CLIENT_LIST_STACKING, _NET_CLIENT_LIST or both.
and since this information is crucial for pager implementation,
i suggest saying:

"Both properties MUST be set and updated by the Window Manager. Both propertis
MUST contain all clients currently mapped and only differ with respect to the
order the clients are listed in."

(i've come across window managers that tried to be clever and
skipped SKIP_TASKBAR clients from the CLIENT_LIST.)

>
>   [[MM: This is simple. Does anyone feel we need a faster mechanism based on incremental updates? (based selection query
>   + ADD/REMOVE updates, we must be careful about race conditions if we do this)? It would be nice to have a query for
>   managed windows in Z-order, for external implementations of Alt+Tab]]

i think this comment can be removed now.


>_NET_NUMBER_OF_DESKTOPS
>
>_NET_NUMBER_OF_DESKTOPS, CARDINAL/32
>
>   This property SHOULD be set and updated by the Window Manager to indicate the number of virtual desktops.

the same reasoning applies here to say:
"This property MUST be set and updated by the Window Manager
to indicate the number of virtual desktops."

>
>   If a Pager wants to delete/insert a certain desktop, it MUST send a _NET_{INSERT/DELETE}_DESKTOP to the root window
>   (l[0] = desktop to insert/delete, insert MUST also work for appending one desktop. When a desktop is deleted, the
>   window manager SHOULD move its windows to the newly active desktop. This operation SHOULD NOT be performed by
>   Applications.

a window manager author may decide to make the number of desktops a compile
time option, or at least keep it fixed after the configuration file has been
read. also it should be clear that _NET_{INSERT/DELETE}_DESKTOP refer to client
messages. so we better say:

"To change the number of desktops, a Pager can send a _NET_INSERT_DESKTOP
or _NET_DELETE_DESKTOP client message to the root window to insert or delete
certain desktops respectively. 
Such a client message consists of one CARDINAL/32 containing the desktop that
is subject to insertion/deletion.
The Window Manager should honour insertion requests of desktops equal to or
greater than _NET_NUMBER_OF_DESKTOPS with appending of a new desktop.
When a desktop is deleted, the window manager SHOULD move its windows to the
newly active desktop. This operation MUST NOT be performed by Applications."


>_NET_DESKTOP_NAMES
>
>_NET_DESKTOP_NAMES
>
>   The names of all virtual desktops in UTF8 encoding. This property MAY be changed by a Pager or the Window Mangaer at
>   any time. When a desktop is added or removed, the Window Manager MUST update this list.

i'd prefer having this property be changed through client messages as well,
and let the window manager handle updates to ensure that the property stays
in a consistent state:

"_NET_DESKTOP_NAMES

_NET_DESKTOP_NAMES, STRING/<number of desktops>
 
The names of all virtual desktops in UTF8 encoding. This property can be
changed by a Pager through sending a client message to the root window of
type _NET_DESKTOP_NAMES, format STRING/<number of desktops>. The Window Manager
MUST keep this property up to date, according to such client messages or
desktop insertions/deletions."


>_NET_WM_DESKTOP
>
>_NET_WM_DESKTOP <desktop>, CARDINAL/32
>
>   Cardinal to determine the desktop the window is in (or wants to be) starting with 0 for the first desktop. A Client
>   MAY choose not to set this property, in which case the Window Manager SHOULD place as it wishes. 0xFFFFFFFF indicates
>   that the window SHOULD appear on all desktops/workspaces.
>
>   The Window Manager SHOULD honor _NET_WM_DESKTOP whenever a withdrawn window requests to be mapped. When being in
>   another state (iconified or mapped), a Pager may request a change by sending a _NET_WM_DESKTOP client message to the
>   root window (window is the respective window, type _NET_WM_DESKTOP, format 32, l[0]=<desktop>)
>
>   The Window Manager MUST keep this property updated on all windows.

ok, here the use of SHOULD doesn't make a whole lot of sense, according to rfc2119:
	3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
	   may exist valid reasons in particular circumstances to ignore a
	   particular item, but the full implications must be understood and
	   carefully weighed before choosing a different course.
i.e. if the client does not set this property, the window manager should place
it as it whishes, except if there exist valid reasons to not do so. but where
would it place the window in such a case? ;)
and i don't think it is good habit to put the client message formats into
braces, because they are an important part of the specification.
also the 0xFFFFFFFF is superfluous (besides obviously hackish), this is exactly
what _NET_WM_STATE_STICKY is meant to indicate. so i'd rather have this say:

"_NET_WM_DESKTOP

_NET_WM_DESKTOP <desktop>, CARDINAL/32

Cardinal to determine the desktop the window is in (or wants to be) starting
with 0 for the first desktop. A Client would usually not set this property,
in which case the Window Manager can place it according to its placement
policies.
The Window Manager SHOULD honor _NET_WM_DESKTOP whenever a withdrawn window
requests to be mapped. When being in another state (iconified or mapped), a
Pager may request a change by sending a _NET_WM_DESKTOP client message to the
root window, where window is the respective window, type _NET_WM_DESKTOP,
format 32, l[0]=<desktop>. The Window Manager MUST keep this property updated
on all windows.
This property should not be considered at all meaningfull for clients flagged
as _NET_WM_STATE_STICKY in their _NET_WM_STATE property."


>_NET_WM_WINDOW_TYPE
>
>_NET_WM_WINDOW_TYPE, ATOM[]/32
>
>   This MUST be set by the Client before mapping, to a list of atoms indicating the functional type of the window. This
>   property SHOULD be used by the window manager in determining the decoration, stacking position and other behaviour of
>   the window. The Client SHOULD specify window types in order of preference (the first being most preferable), but MUST
>   include at least one of the basic window type atoms from the list below. This is to allow for extension of the list of
>   types, whilst providing default behaviour for window managers that do not recognise the extensions.

using MUST here is absolutely inappropriate, this will present us with a
whole lot of non conformant applications, eventhough we write up a
*window manager* spec here. of course applications may not set this
property at all. and i think we better say "This property can be used by
the window manager..." rather than SHOULD, since common consensus on this
list was that it's up to the window manager how to handle this property,
if at all.


> Tim, perhaps you could expand on some of these for discussion on the list,
> or write them up formally for inclusion in the spec.

i'll handle that in a seperate mail.


> 
> cheers,
> 
> Paul
> 

---
ciaoTJ