Universal window matching

[tryone144]

I've got a prototype working for a more unified way to specify window-specific options. The current setup has multiple arrays of rules to disable a globally enabled option for specific windows, i.e. shadow = true and then shadow-exclude.
A similar approach has already been implemented with the wintypes section.

Overview over current rules and wintypes options

rules	wintypes	mode	function
shadow-exclude	shadow	disable	disable global shadow = true
clip-shadow-above	clip-shadow-above	enable	don't draw shadow above window
fade-exclude	fade	disable	disable global fading = true
blur-background-exclude	blur-background	disable	disable global blur-background = true
focus-exclude	focus	enable	always consider window focused
opacity-rule	opacity	value	set normal window opacity value
invert-color-include	—	enable	invert color of window
rounded-corners-exclude	—	disable	disable global corner-radius > 0
paint-exclude	—	disable	don't draw window (undocumented, only via cli)
unredir-if-possible-exclude	—	disable	don't try to unredirect the screen if it would be possible
—	redir-ignore	disable	don't consider window when trying to redirect the screen again
—	full-shadow	enable	don't clip shadow behind window

The wintype options have higher precedence than the rules.

New option window-rules

My prototype implements a new configuration option window-rules, that takes a list of rule conditions and corresponding options. This could look like the following:

window-rules: (
    {
        condition = "class_g = 'firefox' && window_type = 'utility'";
        options = {
            shadow = false;
            blur-background = false;
            clip-shadow-above = true;
            opacity = 0.8;
        };
    },
    {
        condition = "_NET_WM_STATE@[*]:a *= 'HIDDEN'";
        options = { shadow = false; blur-background = false; opacity = 0; };
    },
);

These take precedence over the existing rules. The first matching rule for a specific option has highest precedence (similar to the existing rules).

However, this approach still leaves open a few questions:

• Should the wintypes and window-rules options offer identical features?
  I think yes, consistency would be nice.
• Do we want to support an inverse rule-set, i.e. disable shadows globally and enable them via a rule?
  This might be more difficult to implement as we currently depend on the global options for some steps. However, the boolean nature of the rule-options implies this is possible.
• Should / can we make this accessible via the command-line options?
  If we are to deprecate the current option-specific rules, we either loose the ability to specify rules via the options (i.e. require libconfig and config-file), or the option interface diverges from the config interface. wintypes is currently only available in the config-file.

[yshui]

Do we want to support an inverse rule-set, i.e. disable shadows globally and enable them via a rule?

I think yes, the rule-set should just be an override of the global options. Although IIRC we do use the global options to avoid doing some processing when they are disabled. Maybe there could be some performance implications.

Should / can we make this accessible via the command-line options?

🤔 I would definitely love to have that. But I couldn't come up a good way to put it in to the command-line interface.

Other things to consider:

• in what order are this rules applied?
• does the matching stop at the first matched rule?

Also, could we automatically convert user's config files to use window-rules?

[tryone144]

But I couldn't come up a good way to put it in to the command-line interface.

Same problem here. We could theoretically try and fetch more than one parameter for a command-line option by fiddling with getop's optind. The first would then be the rule-string (or wintype name) and the second a semicolon-separated list of options similar to the config-file options field. The latter would ideally be parsable without the libconfig dependency.

• in what order are this rules applied?
• does the matching stop at the first matched rule?

The new window-rules rules are currently added after the existing exclude-rules and have therefore higher precedence. The first rule that matches for a given option has the highest priority. This is the same behaviour to the exclude-rules and due to how the c2_match-routine is implemented.

Having said that, the current implementation just fills out the existing c2 rule-trees for the exclude-rules. So matching stops at the first matched rule that specifies the option in question. In the example above, a utility-window from firefox would have an opacity of 0.8, even if it has a WM_STATE_HIDDEN property.

Also, could we automatically convert user's config files to use window-rules?

This should be possible. We should be able to extract all rule-strings from the existing exclude-rules (that either have a fixed boolean value, or a specified value for the opacity). These could then be added to a new config object and printed (I think) or the config modified in place and saved, if the user wants to (i.e. running with --convert-config to convert/remove deprecated options?).

EDIT: Currently wintype options have the highest priority. I think users would usually expect window-rules to override wintype-specific options, so their priority would have to be changed as well.

[vincentbernat]

I think this is quite interesting. To make things simpler, I would suggest:

1. Not allow this option to be used from the command-line.
2. Make this option exclusive to any other non-global options to not confuse users about the order and the specificity. This includes wintypes. In my case, I would be very interested to spend a bit of time to migrate to such a configuration system as the current state is a bit hard to navigate.