questions about _NET_SUPPORTED

[Dan Winship <danw novell com>]

> _NET_SUPPORTED
>
> _NET_SUPPORTED, ATOM[]/32
>
> This property MUST be set by the Window Manager to indicate which
> hints it supports. For example: considering _NET_WM_STATE both this
> atom and all supported states e.g. _NET_WM_STATE_MODAL,
> _NET_WM_STATE_STICKY, would be listed. This assumes that backwards
> incompatible changes will not be made to the hints (without being
> renamed).

This suggests that a compliant Window Manager MAY support any consistent
subset of the hints. (After all, it would be silly to list the specific
atoms supported if the WM was required to support every one of them,
right?) And yet elsewhere the spec says things like:

> For Window Managers that don't support large desktops,
> [_NET_DESKTOP_VIEWPORT] MUST always be set to (0,0).

> [_NET_CURRENT_DESKTOP] MUST be set and updated by the Window Manager.

> The Window Manager MUST then [after receiving a
> _NET_CLOSE_WINDOW] attempt to close the window specified.

etc, which implies that a compliant Window Manager MUST support those
hints/messages, even if it doesn't support the corresponding functionality.

My theory is that these MUSTs are wrong, and the spec should instead say
things like:

> _NET_NUMBER_OF_DESKTOPS
> ...
> A Window Manager that supports multiple desktops as defined in this
> specification MUST list this hint in _NET_SUPPORTED, and MUST set and
> update this property to indicate the number of virtual desktops. If
> this hint is not listed in _NET_SUPPORTED, Clients SHOULD assume that
> the Window Manager does not support multiple desktops, and SHOULD NOT
> use any other other multiple-desktop-related hints.
> ...
> ...
> _NET_CURRENT_DESKTOP
> ...
> A Window Manager that supports multiple desktops as defined in this
> specification MUST list this hint in _NET_SUPPORTED, and MUST set and
> update this property as the current desktop changes.

This is arguably an incompatible change to the spec, as it will un-MUST
several properties and client messages, but it seems clear that this is
what the spec *meant*... OTOH, if there are Clients that will fail
horribly if any of these MUSTs are reduced, then we should update the
description of _NET_SUPPORTED to note explicitly that certain hints are
REQUIRED. (In fact, at least _NET_SUPPORTED and _NET_SUPPORTING_WM_CHECK
are REQUIRED anyway.)


There are also some other ambiguities in the definition of
_NET_SUPPORTED. Eg, "hint" is never defined explicitly. Here is my
proposed replacement text:

> This property MUST be set by the Window Manager to indicate which
> hints it supports, where "hint" means any of the Atoms defined in
> this specification. For hints that consist of both a property and a
> ClientMessage (eg, _NET_NUMBER_OF_DESKTOPS), the Window Manager
> MUST support either both of them or neither of them. _NET_SUPPORTED
> SHOULD also include properties which are only set by Clients, if the
> Window Manager implements some functionality based on them (eg,
> _NET_WM_USER_TIME).
>
> A Window Manager MAY list non-standard hints in this property. A
> Client MUST ignore any hints listed which it does not recognize.
>
> The Window Manager MUST NOT change the value of _NET_SUPPORTED
> after initially setting it.
>
> A complete list of all of the hints defined by this version of the
> specification can be found in Appendix FIXME. A compliant Window
> Manager MUST list at least _NET_SUPPORTED and
> _NET_SUPPORTING_WM_CHECK.

Changes from the current version:

    1. It's made explicit that for property/ClientMessage pairs,
       you have to support both.

    2. It's made explicit that the list should include properties
       that are only read and not set.

    3. The WM is explicitly allowed to add non-standard properties,
       and it's explicitly stated that the Client MUST ignore ones
       it doesn't recognize. (This wasn't stated before, but it was
       always true, since Clients have to be able to deal with WMs
       implementing future versions of the spec.)

    4. The WM is forbidden to change the property after setting it.
       I can't think of any good reason why it would need to, and
       allowing it to would make life more annoying for Clients.

    5. Instead of listing three possible hints, a complete list is
       given in an appendix, removing all ambiguity about whether or
       not something should be listed.

    6. Add REQUIRED hints


I can submit a patch with this change and changes either explicitly
requiring or un-requiring the various other hints, depending on how
people feel.

-- Dan