Re: Comments on 1.0pre3/pre4

["Matthias Clasen" <Matthias Clasen poet de>]

----- Original Message ----- 
From: Rob Hodges <s323140 student uq edu au>
To: Matthias Clasen <Matthias Clasen poet de>
Cc: <wm-spec-list gnome org>
Sent: Wednesday, November 01, 2000 09:08
Subject: Re: Comments on 1.0pre3/pre4


> > 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.  

Yes, of course. If the WM supports a list property, it should always set
it, even if the list is empty.
 
> 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?

That might be worthwhile.
 
> 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.  

Admitted.
 
> > 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.
>

Yes, I just wanted to point out the need for this. 
Any ideas how this could be done ? 
I had thought about having the WM put a _NET_SUPPORTED property 
on each toplevel to indicate what commands it will accept for the window.
It may be less burdensome to use a _NET_NOT_SUPPORTED property though.
 
> > _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.

OK, so taskbars do want to use the icon name. So we should really include
_NET_WM_ICON_NAME, UTF-8_STRING

> 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.

... and also _NET_WM_VISIBLE_ICON_NAME, UTF-8_STRING.  

> > _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 ;)

No problem.

Matthias