yshui / picom

A lightweight compositor for X11
Other
3.94k stars 580 forks source link

[feature] [RFC] universal window rules #1284

Open yshui opened 6 days ago

yshui commented 6 days ago

Problem

picom has many rules that allow the user to customize how each windows are rendered. The way it is implemented currently, we basically have one rule per point of customize. Such as blur-background-exclude for background blurring, fade-exclude for fading, etc. This does not scale well as we introduce more customization possibilities. Look at this:

https://github.com/yshui/picom/blob/05c764c6055570f5f3d648bf740608763c2b2348/src/options.c#L955-L973

This list will keep getting longer if we don't find a better approach. Besides that, it is also:

Proposal

Introducing a new rules option as the unified way to set per-window options. The design is simple:

rules = ({
    # you write a rule
    match = "class_i = 'firefox'";

    # ... and you set options
    blur-background = false;
},
{
    # ... any number of rules can be created
}, )

Supported options

All options that make sense as a per-window option will be supported. Such as fading, blur-background, shadow, shadow-color, shadow-radius, corner-radius, opacity, animations, full-shadow, redir-ignored, etc.

Multiple matching rules

This style of rules naturally comes with the question of what should happen if multiple rules match. Simply stopping at the first match doesn't really work for us, because that forces user to write very specific rules so they don't overlap. This is difficult and can be confusing.

So instead, picom will always try all of the rules, and combine the options. If the same options is set multiple times in different rule blocks, then the one encountered first in the order of how they appear in the configuration file will be used.

Deprecation plan

No deprecation is planned. All the old rule options, as well as wintypes, will continue to work. But users are encouraged to use the new rules option instead of the old ones. When both styles of rules are present in the configuration, the new rules will be matched first, and only when none of the new rules matches, will picom try any of the old rules.

pijulius commented 6 days ago

@yshui Love the idea!

absolutelynothelix commented 5 days ago

i don't like that "no deprecation is planned". it is "confusing to have both rules, and the wintypes option" and we add yet another way to configure windows.

yshui commented 5 days ago

we add yet another way to configure windows.

The point is rules is self sufficient and can replace all of the old rule options and wintypes.

If you use the old options then you also need to use wintypes, and it's unclear how they interact.