Re: Comments on 1.0pre3/pre4

["Rob Hodges" <s323140 student uq edu au>]

> And a list of allowed values for _NET_SUPPORTED (although I strongly
> question the usefulness of _NET_SUPPORTED):

I think if you don't have _NET_SUPPORTED you must make it clear that
eg. _NET_CLIENT_LIST *must* be set on the root window, even when the
WM has no managed clients.  Otherwise a taskbar cannot see if that's
available when it starts up, which is desirable.  

Perhaps if something is not included in _NET_SUPPORTED, it also could
be said to imply that any of those properties must be stale leftovers
of another WM and should not be trusted?

Also I think it is definitely required for _NET_WM_MOVERESIZE -- else
applications cannot decide whether they should display the special
grips this is designed for.  It would seem pretty dumb to show the
grips if they didn't work.  

> _NET_WM_STRUT and _NET_WORKAREA must be explained in more detail.
> 
> It is my understanding that the strut quadruples specify a reserved
> border around the screen whose width can vary for the four
> sides. The border thickness is specified in _NET_WM_STRUT in the
> following order: left, right, top, bottom.

That is a much better description of struts than is currently in the
spec.  

And I agree with adding limiting values; it should be clear for all
properties whether (0,0) refers to the top-left corner of the physical
screen or of the virtual desktop, and whether "top, bottom, left,
right" refers to border widths or co-ordinates.  

> What about windows which can't be maximized or shaded (e.g. because
> they are not decorated with a titlebar) ? This information is not
> currently available to pagers/taskbars, so they can't remove the
> corresponding items from their menus.

This would be nice...  On a related note, most themes currently
display a maximise button even on non-resizable windows (IIRC MS
Windows actually greys out the maximise button in that case -- there
is a bit more polish about that approach).  However I'm sure such
hints could be compatibly added in a later version of the spec, if
people are loath to add any more features at this stage.

> _NET_WM_ICON_NAME ? It has been proposed, why isn't it included ?
> Maybe this has been neglected since most of the stuff addressed by
> the spec kind of assumes that no icons are displayed.

If true, that's a misguided assumption.  Most taskbars show icons, and
the difference between WM_NAME and WM_ICON_NAME is usually that the
latter doesn't include the name of the app -- since that is not needed
if you have an icon.  So the buttons on a taskbar could go from
reading ["Netscap..."] ["Netscap..."] etc. to reading ["Slashd..."]
["freedes..."] etc., which is obviously a lot more informative.

Some apps (Netscape is currently one of them) don't seem to understand
this and just use the same string for both -- if _NET_WM_ICON_NAME is
included, it would be worth noting in the spec that this is what the
difference is meant to be (at least for apps that show document names.
Obviously, xterms should have "xterm" in both).

However if it's to be included, there should probably also be a
_NET_WM_DISPLAYED_ICON_NAME.  To obtain this, the WM would have to
apply the same transformation to _NET_WM_ICON_NAME as it does to
_NET_WM_NAME.

> _NET_WM_ICON_GEOMETRY Is this really a good idea ? It feels very
> hackish to expect the WM to display an animation, but not handle the
> icons. 
> I'd say we should rather add instructions for detecting the window
> transition from normal to iconic state by third-party apps. Then the
> iconbox can handle the animation itself.

I think it does no harm to include this -- if iconboxes want to do
their own effects they can just watch for PropertyNotifies and choose
not to set this property, no?  And the spec doesn't actually require
this to be implemented by WMs.  Somebody must have wanted it, for it
to get in there; everyone that thinks it's dumb can just ignore it.

It's better that it be a purely optional part of the spec than
implemented differently for each WM that wants to do things this way.
At least iconbox/taskbar authors that can't be bothered creating
effects can still get them for free from the maximum possible number
of WMs.  (Of course, this is the view of a taskbar author ;)

Cheers, 
-Rob