The Nature of Rules and External Rules
Rules in bspwm are not conditional statements evaluated when you write them. They are data structures stored in a list, checked whenever a new window appears. When you execute bspc rule --add Gimp state=floating, you are appending an entry to bspwm’s internal rule list that says : “if class name matches Gimp, apply the consequence state=floating”
Rules can specify multiple consequences separated by spaces. bspc rule --add Firefox desktop=three follow=on means windows with class Firefox should be sent to desktop three, and focus should follow them there. Consequences can include desktop, monitor, state, layer, split_dir, split_ratio, hidden, sticky, private, locked, marked, center, and others.
The split_dir consequence is particularly powerful because it allows you to predefine how a window will be inserted into the tree. If you know that terminal windows should always split to the east of the focused window, you can add a rule with split_dir=east and every new terminal will automatically behave as if you had manually preselected east before opening it.
External rules extend this system by allowing rule consequences to be computed at runtime by an arbitrary program. You set the external_rules_command configuration value to point to a script, and bspwm will execute that script for every new window, passing the window ID, class name, instance name, and any intermediate consequences from built-in rules as arguments. The script can perform any computation—it can check the window’s title, query external databases, inspect system state, or use machine learning—and it outputs consequences in key=value format.
Note
This makes bspwm’s rule system Turing-complete.
Any decision you can express as a program can be implemented as a rule. You could write an external rule script that assigns windows to desktops based on current time, sending email clients to desktop one during work hours and entertainment applications to desktop two during evenings. You could assign windows to monitors based on available memory or CPU load. You could implement complex tiling patterns by computing split directions algorithmically.
Tip
Want dynamically changing rule?
The limitation is that rules are evaluated only when windows are mapped. They do not continuously re-evaluate. If you want dynamic behavior that responds to changing conditions, you must implement that as a separate daemon that subscribes to bspwm events and sends commands based on those events.