Some suggestions for spec clarifications

["Rob Hodges" <s323140 student uq edu au>]

Hi, I'm a small-time taskbar author.  I haven't been subscribed to
this list until now but I've been occasionally reading the spec as
it's evolved (and have been mostly very pleased to see the thought
that you've all put into it).

I've been reading through the 1.0pre3 spec and there are a few things
I'd like to see clarified.  I'm sure I could determine their meaning
by looking through the list archives, but I think it's important that
they should be clear in the spec document itself.  Some are perhaps
rather nitpicky, but I think it would be nice if the final document
reflected the great deal of thought that has obviously gone into it.


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


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

This section is also not explicit about what happens when a window
first sets (or changes) this property.  Should (must? may?) the WM
resize maximized apps to the new correct size?


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


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.


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 hope that all this is helpful and is not taken as unduly critical;
of course I don't have the talent or knowledge of most of the people
here, but I have a fresh set of eyes and these are the areas I felt
the spec was not as clear as it ideally should be.  

Cheers,
-Rob