Re: over-MUSTiness in the spec



Soeren Sandmann wrote:
> The use of MUST means 'other applications, including but not limited
> to the window manager, can rely on pagers sending a 
> _NET_CURRENT_DESKTOP message when they wish to switch virtual 
> desktop'.

If a Client wants to know when a property changes, it needs to watch for
PropertyNotify events on the root window. Watching for the ClientMessage
is no good, because it has no way of knowing whether or not the WM will
act on the request. (But the WM MUST update the _NET_CURRENT_DESKTOP
property when the desktop changes.)

Lubos Lunak wrote:
> That MUST means that the client should change the property by asking 
> the WM and not by fiddling with it itself.

If we want to say that clients MUST NOT fiddle with the WM's properties,
then we should say, at the top of the Root Window Properties section,
that clients MUST NOT fiddle with the WM's properties. The current spec
does not actually forbid that in most cases.

> most of those sentences now 
> read like if those required ways of changing things were just some 
> kind of convenience methods that one is not required to use.

OK, but all of the messages I *didn't* change in my patch were already
using "can". Should we change those to "MUST"?

Currently we have:

Pager/Client "can" send:
    _NET_NUMBER_OF_DESKTOPS
    _NET_DESKTOP_GEOMETRY
    _NET_DESKTOP_VIEWPORT
    _NET_MOVERESIZE_WINDOW
    _NET_WM_MOVERESIZE
    _NET_WM_DESKTOP

Pager/Client "MUST" send:
    _NET_CURRENT_DESKTOP
    _NET_ACTIVE_WINDOW
    _NET_SHOWING_DESKTOP
    _NET_CLOSE_WINDOW
    _NET_REQUEST_FRAME_EXTENTS
    _NET_WM_STATE

Pager "SHOULD" send:
    _NET_RESTACK_WINDOW

_NET_MOVERESIZE_WINDOW, _NET_WM_MOVERESIZE, and _NET_RESTACK_WINDOW are
all clearly not MUST, because they're alternatives to ConfigureRequest.
The others just seem to be inconsistently assigned based on who wrote
the text.

-- Dan



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]