Rework rules system

[koekeishiya]

Sometimes it would be useful to apply a rule only once to known windows, and forget about it -- instead of adding a permanent rule that will also apply to new windows that are created. Basically, it will only apply the rule effects to known windows at the time instead of storing the rule for future use.

The rule --add command now takes an optional --one-shot modifier.

e.g:

Current: yabai -m rule --add [<ARGUMENTS>]

New: yabai -m rule --add [--one-shot] [<ARGUMENTS>]

[kinglouie]

IIRC in bspwm this features works a little different, for example in bspwm you can define a oneshot rule for a specific app to launch on a specific space and then launch the app. the rule is applied to the launched app and then deleted. This is really usefull to create a layout on system boot but afterwards not to be constrained by rules.
Maybe your proposal to only apply the rule to existing windows could have another name to not confuse it with the bspwm functionality.

[koekeishiya]

Not sure what terminology bspwm uses for its features, but I don't really know of a good word to substitute it with?

The meaning should basically convey something that is

done, produced, or occurring only once.

[koekeishiya]

The best alternative I can think of would be something like --add --once or --add --apply-once

[kinglouie]

If I understand your proposed function correctly, the rule is never persisted to the rules database so --add may be already a little confusing/misleading.
In the case of bspwm, having --one-shot as a parameter to the add command is logical because the rule is persisted to the rules list, but deleted after it is applied once.

Maybe a signature like yabai -m rule --apply [<ARGUMENTS>] would be more descriptive of what is actually happening?

[koekeishiya]

That is a fair suggestion. I originally did not do it that way for code structural reasons, but it is not really an issue.

[kinglouie]

also this way --add would stay an async command and --apply and --reapply would be synchronous only.

[koekeishiya]

I'll actually merge it into a single --apply I think. No need to have --apply and --reapply once I do a little code restructuring. The API would be --apply [<RULE_SEL> | <ARGUMENTS>] basically.

[koekeishiya]

also this way --add would stay an async command and --apply and --reapply would be synchronous only.

That isn't really the case though is it? --add itself performs an --apply already today in the existing version, automatically when it is added. Maybe that behaviour of --add should be removed now that these changes are made.
Basically, adding a rule today will apply those parameters to all known existing windows at the time the rule is added AND it will apply to all windows that are created afterwards. Maybe add should only affect new windows that are created after the rule is added.

I have not really thought all that deeply about this originally when rules were implemented, because I usually don't restart yabai during an active workflow/login session; only at boot or before I set up things initially.

[kinglouie]

you're right, it would make sense to remove the --apply part of --add. With this change it also would be easier to add a bspwm like --one-shot to --add at a later time.

At the moment I don't have it scripted to create manual layouts on yabai startup like I had in bspwm with the --one-shot. What would be the way to do this in yabai?

[koekeishiya]

At the moment I don't have it scripted to create manual layouts on startup like I had in bspwm with the --one-shot. What would be the way to do this in yabai?

I haven't actually attempted this myself , so not competely sure how I would approach it and if the necessary facilities are in place. My workflow these days is not very complex, to put it mildly.

I could leave the --one-shot part in for the add command and remove the --apply part of --add.
Introduce the separate --apply command (and merge it with --reapply).

Then you could have the following states:

Add rules that automatically apply to new created windows.
Add rules that automatically apply to new created windows ONCE and removes itself.
Apply properties defined through an existing rule (or all existing rules) on demand, for already known windows
Apply properties defined through an on-the-fly rule, for already known windows

To allow for manual layouts on startup (in a non janky way) there likely has to be other changes, but the above structure would be a start, I think.

[kinglouie]

Add rules that automatically apply to new created windows.
Add rules that automatically apply to new created windows ONCE and removes itself.
Apply properties defined through an existing rule (or all existing rules) on demand, for already known windows
Apply properties defined through an on-the-fly rule, for already known windows

this is 100% for me :)

--one-shot rules really open a lot of possibilities for scripting. I had a script I really miss, It took a path as an argument and would create a neat coding layout with terminal and code editor on the current space.

[koekeishiya]

Do you happen to know how bspwm handles the one-shot rule in the following scenarios?

1. When opening e.g Iterm or Terminal on macOS it can restore x amount of windows. Should the one-shot rule apply to all these windows since they all originate from the same application_launched system event? I assume the answer is yes.

2. When opening some applications, e.g Discord. It will first create a splash-screen window or w/e, which is later destroyed and a new main window is created. A naive implementation would have the splash-screen window "eat" the one-shot rule, and the main window will not have the rule applied. How would bspwm handle such a situation?

Nr1 above is relatively simple for me to handle, just an implementation detail that needs to be taken care of.

N2 is more tricky, because that depends on our ability to detect whether something is a dialog/sub/child window or an actual main window, and this is quite problematic... See #2046 for some rambling thoughts.

[kinglouie]

I really can not remember for No. 1, because i hate window restoration and try to disable it whenever possible.

For No. 2 I remember that I had to tweak some one-shot rules e.g. by regexing on the window title to not hit the splash screen with the rule.

[koekeishiya]

For nr1 I will have the one-shot rule apply to all those windows. I personally don't really use these restoration features either, but that sounds like the intuitive approach to me.

As for nr2, I'll start with a naive approach and the "rule maker" will have to take some care with respect to these applications.

And let's take it from there? Thanks for chiming in here btw. Some design decisions are more difficult, so having someone to spar with is very helpful.

[kinglouie]

sounds both good for me! As soon as you're ready, I will gladly have a testing session with the one-shot functionality and report back to you. Really glad I could help you with this :)

[koekeishiya]

Implemented on master.

--add [--one-shot] [<ARGUMENT>]

Add a new rule. Rules apply to windows that spawn after said rule has been added.
If --one-shot is present it will apply once and automatically remove itself.

--apply [<RULE_SEL> | <ARGUMENT>]

Apply a rule to currently known windows.
If no argument is given, all existing rules will apply.
If an index or label is given, that particular rule will apply.
Arguments can also be provided directly, just like in the --add command.
Existing --one-shot rules that have yet to apply will be ignored by this command.

[koekeishiya]

When a window matches multiple rules, all relevant rule effects will be combined before the final determined set of effects are applied to the window. See #1383 for details.

[koekeishiya]

Fixed in v7.0.0.

[zifeo]

I understand that moving from 6.x to 7.x requires us to add an --apply rule whenever --add was used previously in .yabairc, otherwise the open windows will be initially "tracked" (I turn off management for specific apps) until closed and reopen. Is my understanding correct?