> _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 _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list