[Usability]Window titles and WM_* properties

[Gregory Merchan <merchan phys lsu edu>]

Right now, most applications seem to be encoding the complete string that
should be displayed in a window title. This is wasteful of screen space and
memory and is also prone to error. Screen space is wasted when the name
appears places like the window list and perhaps even in the frame itself.
Memory is wasted by storing the same string (or a subset) multiple times.
Errors can occur when two instances of a program do not know of each other's
existence and thus fail to differentiate themselves by title.

There is a better way to handle this.

An application's windows have various properties which are used by the
window manager to control the display of titles, frame controls, and others.
Setting the Extended (?) Window Manager Hints aside for the scope of this
email, the relevant properties for primary windows are WM_NAME and WM_CLASS.

WM_NAME is a text-type which is stored with indication of it's encoding.
Usually this is type STRING, but UTF8_STRING is also valid.

WM_CLASS is, unfortunately, of type STRING, but I'm not aware of any apps
named so that they could not fit that. It is presently set automatically to
the application binary name, but the API exist to set it explicitly.
The automatic setting can, of course, be improved if need be. This property
is actually an array of 2 strings with WM_CLASS[1] being most similar to the
application named desired for titles.

By letting the window manager show normal window titles as:

 printf ("%s - %s", WM_NAME, WM_CLASS[1]);

the task of writing and storing the application's name need only be
done once per binary. For those window managers not doing this, the most
important part of the name is still displayed so the corner case of
non-standard window managers is not of significantly less utility.

Another benefit of allowing the window manager to concatenate strings
for the full window title is that it can compensate for running the same
app twice with the same name in each instance:

 printf ("%s %d - %s", WM_NAME, second_or_later_instance_number, WM_CLASS[1]);

Thus the burden of ensuring a unique window title is removed from the
application programmer, who would otherwise have to get the name of every
existing window before opening one.

For this other types of windows, other schemes may be preferred. Perhaps
some would use the WM_WINDOW_ROLE property.

By making use of what is already available, but too often ignored, we can
both ease the burden of application programmers and provide a more
consistent and useful interface for the user.


Cheers,
Gregory Merchan