#6 icewoed-1.6: WM_CLASS/WM_NAME fix

[Thomas Zajic]

The enclosed patch fixes icewoed to handle a window's WM_CLASS property the way it is intended to be used in IceWM. IceWM's documentation on this topic is a bit confusing, admittedly, so here's an example to (hopefully) make things clear:

[zlatko@disclosure]:~$ xprop | egrep "WM_(CLASS|NAME)"
WM_CLASS(STRING) = "xterm", "XTerm"
WM_NAME(STRING) = "mc - ~/tmp"

IceWM can handle window options based on the name part ("xterm"), the class part ("XTerm"), or a combination of both parts ("XTerm.xterm") of the WM_CLASS property. Newer versions of IceWM can also combine either of these with the WM_ROLE property. IceWM can *not*, however, handle window options based on the WM_NAME property ("mc - ~/tmp"), which is, unfortunately, exactly what icewoed uses instead of the name part of the WM_CLASS property. From IceWM's help:

"winoptions file is used to configure settings for individual application windows. Each line in the file must be in one of the possible formats:

window_class.window_name.window_role.option: argument
window_class.window_name.option: argument
window_class.window_role.option: argument
window_name.window_role.option: argument
window_class.option: argument
window_name.option: argument
window_role.option: argument

Each window on the desktop has (should) class and name resources associated with it. Some more recent applications will also have a window role resource, though not all do. They can be determined using the xprop utility. xprop should display a line like this when used on a toplevel window:

WM_CLASS = "name", "class"

and may also display a line like this:

WM_WINDOW_ROLE = "window role"

..."

Note that in the context of this help text, "window_class" and "window_name" does *not* correspond to the WM_CLASS and WM_NAME properties, but to the "name" and "class" parts of the WM_CLASS property!

[Thomas Zajic]

Fix for WM_CLASS property handling

[Thomas Zajic]

Logged In: YES
user_id=150806

UPDATE: I just noticed that IceWM's actual behaviour differs from what is described in its help files - I filed this as a bug against IceWM, see http://sourceforge.net/tracker/index.php?func=detail&aid=1004404&group_id=31&atid=100031 for details. Therefore, while icecc is technically correct and consistent with IceWM's documentation, and produces a correct winoptions file according to the specifications, the winoptions file itself doesn't produce the expected results with IceWM - until the IceWM developers agree on the proper format/parsing of the winoptions file, I consider this is a bug in IceWM, not in icewoed!