Re: [Usability]Window titles and WM_* properties

[Gregory Merchan <merchan phys lsu edu>]

On Fri, Mar 01, 2002 at 06:51:36PM -0500, Havoc Pennington wrote:
> 
> Gregory Merchan <merchan baton phys lsu edu> writes:  
> > While you're at it, you might admit you were wrong rather than now
> > trying to push the matter aside as irrelevant.
> 
> CLASS is used for other purposes, and should not be overloaded to
> construct the title. Especially since many legacy apps can't change
> the value of this property without breaking lots of user stuff, and
> especially since it is of type STRING.

The class part of WM_CLASS should already be the application name.

Anyone running sawfish can check this by running:

  sawfish-client -e "(mapcar window-class (managed-windows))"

Right now, my output is:
  ("XConsole" "Emacs" "XTerm" "galeon_browser" "tkirc" "tkirc" "tkirc" "galeon_browser" "XTerm" "Emacs" "XTerm" "XClipboard" "galeon_browser")

A few examples by `xprop | grep WM_CLASS`:

WM_CLASS(STRING) = "xterm", "XTerm"
WM_CLASS(STRING) = "emacs", "Emacs"
WM_CLASS(STRING) = "xclipboard", "XClipboard"
WM_CLASS(STRING) = "win0", "tkirc"
WM_CLASS(STRING) = "win1", "tkirc"
WM_CLASS(STRING) = "xfig", "Fig"
WM_CLASS(STRING) = "Navigator", "Netscape"
WM_CLASS(STRING) = "bookmarks", "Netscape"
WM_CLASS(STRING) = "fileBrowser_popup", "Netscape"
WM_CLASS(STRING) = "xpdf", "Xpdf"
WM_CLASS(STRING) = "gv", "GV"
WM_CLASS(STRING) = "gimp_startup", "Gimp"
WM_CLASS(STRING) = "toolbox", "Gimp"
WM_CLASS(STRING) = "tip_of_the_day", "Gimp"
WM_CLASS(STRING) = "new_image", "Gimp"
WM_CLASS(STRING) = "image_window", "Gimp"
WM_CLASS(STRING) = "gconf-editor", "Gconf-editor"
WM_CLASS(STRING) = "Galeon", "galeon_browser"
WM_CLASS(STRING) = "bookmarks_edit", "galeon_browser"
WM_CLASS(STRING) = "dialog_filesel", "galeon_browser"
WM_CLASS(STRING) = "lyX", "XForm"
WM_CLASS(STRING) = "selectDocumenttoOpen", "XForm"

As you can see already, some of these aren't following the spec; only
a few present a problem. These bugs should be removed, not kluged around.
For some apps, the WM_NAME now encoded will have to be changed.

Oddly enough, The Xlib Programming Manual says, "The window manager
uses [the name part] for the titlebar of the window." I can't find
the cause for that to be there, but clearly the idea isn't completely alien.

> I'm sorry you think I'm wrong, I don't agree.

Too bad that doesn't change the fact.

> In any case it's in no way a usability issue; the usability issue is
> what to display, this implementation detail is for wm-spec-list.
> 
> Havoc

It is a usability issue insofar as the HIG needs to say what should be set
to what by applications and what window managers should do with that
information. Interface guidelines that do not take into account the
limitations or affordances of the underlying platform are a disservice
to the developers and ultimately the end-user. The CDE guidelines do this.


It's a shame that so few people are willing to do what must be done
to make a useful free graphical computing environment.


Ciao,
Greg Merchan