My comments on the WM spec

[Owen Taylor <otaylor redhat com>]

Following up on the discussion over the last few days, and
also because people are interested in finalizing the
spec, I just took a careful pass over the WM spec looking
for remaining issues, and actually, I found quite a few.

I'm still working on adding support for the hints into the
GTK+ codebase, so I may find a few more issues over the
next few days, but I wanted to get these out as soon
as possible.

A lot of the following is basically editorial for the spec -
suggesting clarification or pointing out missing information.
But there are a few places where I think the actual protocol
needs to be changed as well.

Regards,
                                        Owen

_NET_NUMBER_OF_DESKTOPS

 I find the language 

   _NET_VIRTUAL_ROOTS MUST be set  store the new number of desktop
   virtual root window IDs 

 a bit confusing. 

 I would suggest:
   
   The contents of _NET_VIRTUAL_ROOTS MUST be altered so that the
   number of window IDS it contain is new_desktops_number.

 (If that is the proper interpretation; I'm not completely sure
 about _NET_VIRTUAL_ROOTS, see below)

 I would also suggest that language be added indicating that
 if _NET_CURRENT_DESKTOP need to be changed or windows need
 to be moved to a different desktop, these changes must
 be changed _before_ _NET_NUMBER_OF_DESKTOP is changed.

_NET_DESKTOP_GEOMETRY

 Its probably worth saying that this size must be equal or
 greater than the actual dimensions of the screen
 as determined by ScreenWidth, ScreenHeight. 
  
 [ Current proposals to make it possible to change the size of the
 screen on the fly might cause this to be momemtarily violated when 
 changing screen size ]

 The specification of the format for _NET_DESKTOP_GEOMETRY 
 client messages is missing. 

 Also, I would recommend making this section correspond to
 _NET_NUMBER_OF_DESKTOPS by saying that the window manager is not
 required to honour _NET_DESKTOP_GEOMETRY client messages.

_NET_DESKTOP_VIEWPORT

 Might also be useful to specify the constraints that 
 
  0 <= x < desktop geometry width - ScreenWidth
  0 <= y < desktop geometry height - ScreenHeight

 Somewhere, the spec should to specify whether coordinates for client
 windows when mapping the window or in ConfigureRequest are taken with
 respect to the viewport origin or the desktop origin. I believe the
 standard is to use the desktop origin, but would have to check what
 various window managers do.

 Again the client message format is missing

_NET_DESKTOP_NAMES

 The type and format are not specified. Is this the standard
 NUL-separated list of strings?

 Also, note typo: "Window Mangaer" 

_NET_SUPPORTING_WM_CHECK

 "set with the same value" is potentially unclear. Better to say
 "also set to the ID of the child window". And I think it
 is useful to extend the rational here: the property on the
 child window is used so that an active window manager can
 be distinguished from a stale _NET_SUPPORTING_WM_CHECK 
 property that happens to point to another window. If the
 _NET_SUPPORTING_WM_CHECK window on the client window is missing
 or not properly set, clients should assume that no conforming
 window manager is present.

 Reading over the ICCCM again, I realized that this really
 is the wrong way of doing things - really we should be
 working on top of the selection mechanism described in
 sections 2.8 and 4.3. The X selection mechanism is meant
 the way in X to control ownership of shared resources,
 and the ICCCM describes how starting one window manager
 should cause the previous window manager to cleanly give
 up control of the root window. Of course, I don't know if any window
 managers actually conform to the ICCCM in this respect.

_NET_WORKAREA

 Should say that the coordinates here are taken with respect
 to the the current viewport. (If they are.)

_NET_VIRTUAL_ROOTS

 Is this a) an (unordered) list of all virtual root windows other 
 than the real root window, or b) a list of the window that
 corresponds to each desktop, either real or virtual?

 I'm a little nervous about including this since it is known
 that using virtual root windows introduces a number of problems
 for various operations (the ICCCM claims that a protocol 
 extension would be needed to properly implement virtual root
 windows.)

_NET_CLOSE_WINDOW

 There is a formatting problem with client message format 
 specification.

_NET_WM_MOVERESIZE

 A thing to be careful about here is that this operation is
 essentially talking about transferring a pointer grab from
 one window to another. It needs to be pointed out that the
 window manager has no guarantee of getting the release from
 the mouse click that started the operation, and needs to
 check the state field of motion events to safely know when
 to release the grab.
 
 (With this protocol there is no way of getting around the fact 
 that a fast press/release/press can be misinterpreted.)

 For proper operation, I think you really should include 
 the mouse button that started the operation, not just the
 x and y coordinates.

 The name of the enumerations probably really should use
 North,South,East,West, instead of top,right,...to correspond with
 similar names used in X elsewhere.

_NET_WM_NAME

 The property type for this property isn't specified - I would
 suggest UTF8_STRING. _NET_WM_ICON_NAME is missing.

_NET_WM_STATE

 I don't have concrete suggestions here, but I will note that
 this property feels very hackish to me:

  - It groups together different things

    - current state of the window (SHADED/MAXIMIZED)
    - the way the window should be treated
      (modal, skip taskbar, sticky)

  - When mapping a window, does a missing atom mean 
    that the state should is "unset" or "not specified" - 
    this doesn't matter so much for, say, SHADED,
    but for MODAL and SKIP_TASKBAR, it is quite likely
    that the window manager may, e.g., determine automatically
    determine that a window should be MODAL by examining,
    for instance, its WINDOW_TYPE and/or TRANSIENT_FOR
    properties.
 
  - The concept that exactly two properties may be changed
    together seems very odd to me.

  Assuming that we want to keep mixing all these types of "state"
  together, the way I would do this property is to make it
  a bitfield, or actually, two bitfields - one for the bits 
  that are present, and one for the the state of these
  bits.

  The client message would then include a bitfield, and an
  operation - set, clear, toggle, and unset_to_default.
  But I really don't understand the coherence of the different 
  atoms currently in the property.

_NET_WM_ICON_GEOMETRY

 How do we resolve who sets this property? What if there
 are multiple task lists?

_NET_WM_ICON

 It currently says that 1 byte should be each of the width and height
 I think this is probably a typo and it is supposed to be the
 first two elements. (This would correspond to the format being 32.)
 If it isn't a typo, it should be changed, since while 256x256
 is just barely big enough for icons for the forseeable future,
 it is limiting, and we might want to use image specifications
 like this elsewhere.

 Using CARDINAL for the property type is a bit suspect, since the type
 of the data is really something a lot more specific than
 just a bunch of cardinals - its a simple image format.

 Using a specific type also is a little more forward looking since we
 could later add additional formats, and only require changes
 to window managers, and not to clients.

_NET_WM_HANDLED_ICONS

 What's the format (and contents?) of this property?

_NET_WM_PING

 Is the window field of the event really supposed to be
 set to the root window? Leaving it set to the client window
 is 

 A problem through out the spec is that the event mask for sending
 events to the root window is not specified. But it isn't possible
 to receive ClientMessage events without setting a mask in
 XSendEvent. Probably this should be specified as 
 SubtructureNotify|StructureRedirectMask, as it is for similar
 events in the ICCCM.

 As noted before, "immediately" should be replaced by
 "as soon as possible".

Implementation Notes:

As noted before, interpreting WM_TRANSFIENT_FOR pointing to the
root window to mean transient for the group breaks legacy applications.
The statement "is extremely unlikely to break anything" is just
wrong; and we should not require or even recommend this 
behavior. (To repeat the argument as to why it is wrong, 

Such hints should either be ignored or be treated to be equivalent to
using "_NET_WM_WINDOW_TYPE_DIALOG" without any explicit
TRANSIENT_FOR properties.

The Window Movement section needs some fixing:

 If you move a window with, for insance, NorthEastGravity to (x,y), the
 effect is _not_ to move the upper left corner of the frame to
 (x,y). Instead, if the size of the window is (width, height)
 _excluding the frame_, then the effect is to move the upper left
 corner of the frame to (x+width,y). 

 Also, the list is missing North,South,East, and West gravity.

For "Killing Hung Processes", it needs to be noted that if a window
does not respond to _NET_WM_PING, it does _not_ necesarily mean that
the process is dead, and window managers MUST ask for confirmation
from the user before proceeding to kill the process.

Throughout the document we have "UTF8" - I would suggest writing this
as UTF-8 instead, as this is the way that it is officially written by
the Unicode consortium. 

The document needs a references section for at least the Unicode
standard and the ICCCM.