Re: My comments on the WM spec (fwd)

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

On 1 Oct 2000 otaylor fresnel labs redhat com wrote:

> I've been having a few problems with my mail recently, and going
> through the log files, it looks like I managed to lose a message
> from you:
>
>  From bhughes trolltech com  Sat Sep 30 13:29:38 2000
>    Subject: Re: My comments on the WM spec
>
> (I don't see this in the wm-spec archives, so it looks like it
> was a private mail to me.)

Hmm... seems it was... I thought I had sent it to both you and the list
(grumble grumble pine grumble)

> Do you happen to still have a copy around?

Forwarded for your viewing pleasure :)

> Sorry for the inconvenience,
>                                             Owen

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

---------- Forwarded message ----------
Date: Sat, 30 Sep 2000 19:27:12 +0200 (CEST)
From: Bradley T. Hughes <bhughes trolltech com>
To: Owen Taylor <otaylor redhat com>
Subject: Re: My comments on the WM spec

On 25 Sep 2000, Owen Taylor wrote:

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

I don't think changing the protocol and/or semantics of anything in the
spec is justifiable.  KDE 2 is due out within 2-3 weeks, which gives up
very little testing time.

> Regards,
>                                         Owen
> 
> _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. 

My implementation uses:

	e.xclient.type = ClientMessage;
	e.xclient.message_type = net_desktop_geometry;
	e.xclient.window = root_window;
	e.xclient.format = 32;
	e.xclient.data.l[0] = desktop;
	e.xclient.data.l[1] = new_width;
	e.xclient.data.l[2] = new_height;

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

Agreed.

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

For completeness, the format I use:

	e.xclient.type = ClientMessage;
	e.xclient.message_type = net_desktop_viewport;
	e.xclient.window = root_window;
	e.xclient.format = 32;
	e.xclient.data.l[0] = desktop;
	e.xclient.data.l[1] = new_x;
	e.xclient.data.l[2] = new_y;

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

I have implemented them this way.  This makes reading the property very
straight forward

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

I agree with Sasha that the coordinates are taken wrt to the screen.

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

Again, my implementation:

    e.xclient.type = ClientMessage;
    e.xclient.message_type = net_close_window;
    e.xclient.window = root_window;
    e.xclient.format = 32;
    e.xclient.data.l[0] = window;
    e.xclient.data.l[1] = 0l;
    e.xclient.data.l[2] = 0l;
    e.xclient.data.l[3] = 0l;
    e.xclient.data.l[4] = 0l;

> _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:

That makes 2 of us :)

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

I have done similar things with Blackbox, and it seems to work.

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

The SelectionOwner for _NET_WM_ICON_GEOMETRY? ... but that doesn't solve
the problem of multiple tasks lists (which seems a bit odd conceptually,
but i wouldn't be surprised if someone did run 2 task lists/bars)

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

is...?

One of the things that I have kept uniform throughout my impementation is
keeping the window field set to the client window for messages to a client
and set to the root window for messages to the window manager.

This allows for one implementation to handle both client and window
manager tasks (which I have done).

>  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.
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
> 

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