Re: 1.9d

[Paul Warren <pdw ferret lmh ox ac uk>]

On 12 Dec 1999, Dan Winship wrote:

> Hi. I'm new here, so so apologies if I complain about something you
> decided not to fix 10 revisions ago...

Ah.  Good to have some fresh eyes on it, for exactly this reason:

> Overall, there's too much of an assumption that the reader already knows
> exactly what the document is about. 

> The intro jumps right into a definition
> of terms, without ever mentioning what we're talking about. You might also
> want to define what "pager"s and "taskbar"s are in the section where you
> say that you're going to refer to both of them as "Pager"s. ("Pager" at
> least is completely non-obvious to anyone who doesn't use a "modern" window
> manager. To me, "pager" means either something that beeps and tells you
> you need to go into work, or a program like "more" or "less".) Other
> non-X-standard words you use without defining include "desktop", "viewport",
> and "dock".

This is probably true.  I suspect that anyone implementing this spec will
know what the terms mean, but it does neeed an intro and some
clarification.

> You occasionally misuse the RFC 2119 words. They should always imply
> conformance/non-conformance with the spec. For example, the sentence:
> 
> 	If a Pager wants to delete/insert a certain desktop, it MUST send a
> 	_NET_{INSERT/DELETE}_DESKTOP to the root window
> 
> means
> 
> 	A Pager that inserts or deletes a desktop without sending a
> 	_NET_{INSERT/DELETE}_DESKTOP to the root window is not in
> 	compliance with this specification.
> 
> which isn't at all what you mean. 

Erm... What I mean is that Pagers MUST NOT delete or insert desktops
themselves.  If they want the number of desktops to be altered (by the
WM), they MUST send the INSERT/DELETE message.

> I think you want to say "can" rather than "MUST".

> There are other cases where you use "MUST" or "SHOULD" where it's
> not explicitly made clear whose behavior you're restricting. E.g:
> 
> 	_NET_WM_STATE_STICKY indicates that a window SHOULD have a fixed
> 	position on the screen, even when the virtual desktop scrolls.
> 
> should be something like:
> 
> 	_NET_WM_STATE_STICKY indicates that the window manager SHOULD keep
> 	the window's position fixed on the screen, even when the virtual
> 	desktop scrolls.

Yes, that's correct.

> It might make sense to split the root window properties and the corresponding
> messages Pagers can send to modify them into separate sections.

Quite possibly, yes.

> There should be an explicit list somewhere of exactly which properties
> can/should/must be listed in _NET_SUPPORTED and _NET_PROPERTIES.

Yes.

> In the comment on _NET_CLIENT_LIST, the parts about ordering need
> clarification. Does "mapping order" mean "the order in which the windows
> were first mapped", or "the order in which they were most recentlymapped"?
> (ie, if I unmap and then remap a window, does it move to the end of the
> list?) For stacking order, you should specify if the first window in the
> list is the top or the bottom. I have no idea what the "Z order" mentioned
> in the comment means if it's not the same as stacking order.

OK, that should be clarified.

> The _NET_NUMBER_OF_DESKTOPS and _NET_DESKTOP_GEOMETRY sections are each
> missing a close paren after the protocol description.

Oops.  It was 4am...  I didn't proof read it properly :-)

> In the description of _NET_DESKTOP_GEOMETRY, "the width and height of each
> desktop" sounds like each desktop could have a different size, which doesn't
> appear to be true.

Indeed.

> The description of _NET_DESKTOP_VIEWPORT (or the introduction) should
> explain "paged desktops". Also, I suspect you mean to require that Pagers
> can only set the viewport to x,y pairs that are specified in the root
> _NET_DESKTOP_VIEWPORT property, but you don't say that. 

No.  The list of x,y's gives the currently active viewport on each
seperate desktop.

> (If not, and the wm doesn't want to allow arbitrary viewports, then
> there needs to be some way for the Pager to know that it failed,
> particularly in the case where the wm doesn't support any viewport
> other than 0,0.)

If the WM doesn't support a viewport other than 0,0, _NET_DESKTOP_GEOMETRY
will be equal to the screen size, and a Pager should not try to move the
view port.

If the Pager tries to set the viewport to an arbitrary x,y, and the WM
does not support it, then the WM should probably round to the nearest
viewport.  The Pager will know that its request was not honored exactly by
watching the VIEWPORT property and seeing what it gets set to.  Do we need
a more positive whole-viewports-only type hint?

> It's not clear what "active" means in _NET_ACTIVE_WINDOW. I would have
> guessed "has the keyboard focus", except that apparently a Pager can make
> a window "active" without setting the keyboard focus...

_NET_ACTIVE_WINDOW essentially means "Taskbar wants to work with this
window".

> If you can't set more than one of _NET_ACTIVATE_VISIBLE_ON_VIEWPORT,
> _NET_ACTIVATE_VISIBLE_ON_DESKTOP, and _NET_ACTIVATE_VISIBLE_EVERYWHERE,
> it might be better to make them be two bits rather than three, with values
> 01, 10, and 11 respectively.

Yes.  I thought we had made those ATOMs for extensibility.  I would still
like to hear more explanation/justification for the degrees of activation.

> _NET_WORKAREA: The text implies the ordering of the array elements is
> "left, right, top, bottom", but isn't explicit. I think normal X
> ordering is "left, top, right/width, bottom/height", like
> _NET_WM_ICON_GEOMETRY uses. 

Thanks - that's a typo.  _NET_WORKAREA should contain two pairs of
co-ordinates left,top,right,bottom.

> But _NET_WM_STRUT seems to explicitly specify the same ordering that
> _NET_WORKAREA implies. This needs to be cleaned up.

_NET_WM_STRUT is not specify pairs of co-ordinates, it is giving an offset
from each edge of the screen.  The order should either be top, right,
bottom, left (ie. clockwise like the bits in MOVERESIZE) or
left,top,right,bottom for consistency with _NET_WORKAREA.

> If the "SHOULD" in _NET_WM_MOVERESIZE is really a "SHOULD", the spec should
> clarify what other value the app can set x_root and y_root to other than the
> position of the click. (I suspect you don't really mean "SHOULD" though.)

I wrote SHOULD intentionally.  The alternative was that the moveresize
event was not initiated by a mouse click eg. by a keyboard event.  On
second thoughts this is probably not ideal:

I would prefer to abolish the different resize directions, and have the
Window Manager figure out what are the allowed resize directions.  Several
window managers already allow you to resize a window by Meta + Right
clicking anywhere in the client window - and they figure out which
directions the window can be sized in purely from where the mouse click
is.  I think that the message should only specify where the click is, and
whether it is a move resize.

> The sentence starting "When being in another state" in the _NET_WM_DESKTOP
> section is very confusing.

It means not withdrawn, but it should be clarified.

> _NET_WM_STATE_SHADED: What does "shaded" mean?

Whatever the WM wants it to mean.  Usually it means that just the titlebar
is visible.

> _NET_WM_STATE_SKIP_TASKBAR: Should TASKBAR be PAGER? 

Hmm.  SKIP_TASKBAR windows should probably show up on a Pager, just not a
TaskBar.

> At any rate, a more generic description (and possibly name) is
> probably in order. ("indicates that this window should not be included
> on lists of active windows"?)

Yes.

> _NET_WM_ICON: The sentence ending "may do" should probably say "may do so".

Noted.

> Is there any reason NET_WM_PING doesn't have an underscore before its name
> like everything else?

I copied that from what Matthias wrote, assuming that he knew something
that I didn't about the naming of ATOMs to be used in WM_PROTOCOLs.  I
have just rechecked the ICCCM, which says that the X Consortium will
maintain a registry of such protocols, but I assume that if we haven't
notified the X Consortium of this protocol, it should have a leading
underscore?

Thanks for going through the spec so thoroughly, Dan.  One thing I that I
think has been learnt from the first Gnome spec is that it needs to be
really tight and specific, otherwise people will go off and implement it
wrongly / differently, and we end up in a mess...

cheers,

Paul