Re:

["Matthias Clasen" <Matthias Clasen poet de>]

> Section 2.1: does _NET_SUPPORTED refer to both messages & properties
> identified by the same atom?  If not, does it refer only to properties
> (and the protocol(s) in Section 5)?  How about client window
> properties that the WM is responsible for, such as
> _NET_WM_VISIBLE_NAME; should those be included in this array?
>
> It might be nice to list all the atoms that can be present here, and
> exactly what their presence implies.  For example, it would appear
> from the spec that if _NET_SUPPORTING_WM_CHECK indicates the presence
> of a compliant WM, then the _NET_DESKTOP_VIEWPORT property *must* be
> set (even if only to {0,0}).  So does the presence of
> _NET_DESKTOP_VIEWPORT in the _NET_SUPPORTED array imply that the WM
> *must* honour the client message requesting a change of viewport, or
> only that it *may* honour it, as specified in Section 2.5 (if the
> latter, why is it even worth having it as one of the atoms that can be
> present there -- its presence wouldn't really tell you anything about
> what you can expect from the WM...)

I doubt that the list of atoms in _NET_SUPPORTED is worth a lot. Clients
that wish to use any of the properties will have to check for their presence
anyway.

> Section 4.6: _NET_WM_STRUT is unclear about what the cardinals should
> be set to.  Actually I'd like to see a rather more commentary about
> how this works.  eg. Let's say a taskbar will be visible at the bottom
> of the physical screen, no matter what the current viewport is.  IOW,
> it will be sticky with respect to both workspaces (desktops) *and*
> viewports.  Should it then set left, right and top to zero and bottom
> to its height?  (Do non-sticky windows that set _NET_WM_STRUT only
> reserve space on the viewport on which they appear, or across the
> entire workspace?  Or is it the former for paging WM's and the latter
> for those that scroll?)

I think that _NET_W_STRUT is expected to be used only on sticky windows.
But you are right that clarification is necessary here.

> Section 2.9: The calculation of _NET_WORKAREA is based on the "current
> page".  Does this mean that it is always less than or equal to the
> pixel dimensions of the physical screen?  (ie., the entirety of
> _NET_WORKAREA is always visible, and is equivalent to the dimensions
> of a maximized window?)  What about WM's that implement scrolling
> rather than paging?  Perhaps "current page" is not the best wording
> here...

I think what is indended is that the geometries are specified relative to
the viewport on each desktop, ie the WM doesn't have to update _NET_WORKAREA
when the viewport moves. This is in line with the expectation that struts
will be placed only on sticky windows. And it also more or less implies that
the workarea is always completely on screen.

> Section 4.7: _NET_WM_ICON_GEOMETRY -- is this property meant to be set
> on the taskbar's window, or on the window of each app that might be
> iconified?  A taskbar might like to keep apps with the same WM_CLASS
> together, which would require the latter.  But the text is not clear
> about this.

On the window of the to-be-iconfied app. The taskbar window may not even be
a toplevel
window (it could be swallowed), thus setting the property there wouldn't
catch
the WMs eyes (and it wouldn't work, since you need a per-app value).

> Section 6.1 refers to desktops.  Reading between the lines of the spec
> indicates that all desktops must be the same size (either that, or
> _NET_DESKTOP_GEOMETRY should be an array of pairs and the
> corresponding client message should either include the desktop to be
> resized or said to refer to the current desktop).  This should
> probably be stated explicitly here to emphasize the point, since
> there's no absolute reason that this should be the case -- only that
> it would be incompatible with the spec.

I tried to clarify the description of _NET_DESKTOP_GEOMETRY: all desks have
the
same size.

> I hope that all this is helpful and is not taken as unduly critical;

very much so, thanks a lot.

Matthias