On Monday 17 April 2006 17:45, Dan Winship wrote:
> > _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,
Correct.
> 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.
No. There's implicit "if supported" prepended.
> 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.
If you think this is not obvious, I suggest you make it more explicit in the
description of _NET_SUPPORTED instead. There's no point in making every
section sound like a disclaimer.
> 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.
Would the idea of not doing this ever occur to anybody? Hmm, ok, apparently
would. But the wording is weird ("must support neither" ... huh?), just "...
MUST support both" should be enough.
>
> 2. It's made explicit that the list should include properties
> that are only read and not set.
That's superfluous. If the WM reads it, it supports it, it's required to list
it. If we do this with everything, there will be still things where one will
be able to find "ambiguities" when trying hard enough, and the EWMH will end
up sounding just like all those huge specs that are pain to read.
>
> 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.
IMHO superfluous again.
>
> 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.
Do we want that? That sounds like asking for trouble when somebody forgets to
update the list (especially given that the spec itself is such a list).
--
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED]
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
