#556 winoptions: WM_CLASS/WM_ROLE handling

[Thomas Zajic]

From IceWM's help system:

"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
[...]
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"
[...]"

Let's take Gimp's brush selection window as an example. xprop says:

[zlatko@disclosure]:~$ xprop | egrep '(WM_CLASS|WM_WINDOW_ROLE)'
WM_CLASS(STRING) = "brush_selection", "Gimp"

So, the proper line to set an icon in ~/.icewm/options should be

Gimp.brush_selection.icon = brushes.xpm

which is the "window_class.window_name.option: argument" format. This, however, doesn't work. It only works if I swap the res_name and res_class part in ~/.icewm/winoptions, like

brush_selection.Gimp.icon = brushes.xpm

which in turn is not a possible valid format according to the help text. Therefore, either the help text or the actual implementation is wrong - which one is it? :-) BTW I haven't checked whether the same problem also occurs with class.role and name.role settings, so there might be more of this lurking.

And while we're at it, a related problem: how does IceWM know if I mean window_class, window_name or window_role when it's reading a line like

foo.icon: foo.xpm

in ~/.icewm/winoptions? What happens if I have

# WM_ROLE
foo.icon: foo-role.xpm
# WM_CLASS(res_class)
foo.icon: foo-class.xpm
# WM_CLASS(res_name)
foo.icon: foo-name.xpm
# WM_CLASS(res_class).WM_CLASS(res_name)
foo.foo.icon: foo-class-name.xpm
# WM_CLASS(res_class).WM_ROLE
foo.foo.icon: foo-class-role.xpm
# WM_CLASS(res_name).WM_ROLE
foo.foo.icon: foo-name-role.xpm

in ~/.icewm/winoptions, will a window with

[zlatko@disclosure]:~$ xprop | egrep '(WM_CLASS|WM_ROLE)'
WM_CLASS(STRING) = "foo", "foo"
WM_ROLE(STRING) = "foo"

get one of the foo.icon icons (which one?), or one of the foo.foo.icon icons (again, which one?). Or, given

# WM_CLASS(res_class).WM_CLASS(res_name)
Foo.foo.icon: foo-class-name.xpm
# WM_CLASS(res_class).WM_ROLE
Foo.foo.icon: foo-class-role.xpm
# WM_CLASS(res_name).WM_ROLE
foo.foo.icon: foo-name-role.xpm

in ~/.icewm/winoptions, which icon will this window

[zlatko@disclosure]:~$ xprop | egrep '(WM_CLASS|WM_ROLE)'
WM_CLASS(STRING) = "foo", "Foo"
WM_ROLE(STRING) = "foo"

get? I guess this basically all boils down to a priority/best-match thing - does the ROLE property override any of the class properties, or vice versa? I assume that more specific settings override more generic ones (ie. class.name.role overrides any of class.name/class.role/name.role overrides any of class/name/role), but what about "equally specific/generic" ones? Is this documented anywhere?

But I digress - first of all, the winoptions format/parsing (class.name vs. name.class) has to be fixed. ;-)

[Marko Macek]

Logged In: YES
user_id=1814

this needs to be totally cleaned up

no class.instance.role.something where anything is optional
and causes confusion.

[Nobody/Anonymous]

Logged In: NO

> This needs to be totally cleaned up.
> No class.instance.role.something where
> anything is optional and causes confusion.

Why not always use the "class.name.role.option" synthax where :

- class is the class name : it can be replaced with "*" to
mean "all" ;
- name is the window name : it can replaced with "*" to mean
"all" ;
- role is the window role : it can be replaced with "*" to
mean "all" ;
- option is the IceWM option : obviously, it must be provided.

With this synthax, if we have :

# class="Foo" ; name="foo" ; role=<no particular role> :
Foo.foo.icon: foo-class-name.xpm
# class="Foo" ; name =<no particular name> ; role="foo" :
Foo.foo.icon: foo-class-role.xpm
# class=<no particular class> ; name="foo" ; role = "foo" :
foo.foo.icon: foo-name-role.xpm

... we could write :

Foo.foo.*.icon: foo-class-name.xpm
Foo.*.foo.icon: foo-class-role.xpm
*.foo.foo: foo-name-role.xpm

Just a proposal. That way, there is no confusion and parsing
should be simpler (no need to "guess" as the synthax is
strict). What do you think?

--
LiNuCe

[Nobody/Anonymous]

Logged In: NO

For class-only matching option, the user would write :

class.*.*.option: value

That's perharps the only "drawback".

--
LiNuCe

[Marko Macek]

Logged In: YES
user_id=1814

something like that would work (I have about 50% implemented)