LGUG2Z
efcc90d279
A workspace rule sends the windows of an application to a workspace: an initial rule once, when komorebi first sees the window, and a permanent rule every time, so that a window the user takes away goes back. A rule is a rule on the window's executable, class, title or path, with a monitor and a workspace index, or the name of a workspace. It comes from komorebi.json (workspace_rules and initial_workspace_rules of a workspace, made again from the file each time it is read) or from komorebic (workspace-rule, initial-workspace-rule, their named forms, and the commands that clear and enforce them). The window manager looks at the rules before it handles each event about a window it manages, and again when the configuration is loaded, so the windows that were open when the daemon started are sent too. A window that leaves the workspace in front is taken out of the layout and hidden, as the back of a stack is, and it is put on the desktop of its new workspace, which is what it comes back to and is tiled on when that workspace is shown. A window that moves between workspaces that are not in front is put on the desktop of its new workspace as well. A floating window that goes to another monitor is moved onto it, and a workspace that does not exist yet is made.
3.9 KiB
Workspace rules
A workspace rule sends the windows of an application to a workspace. It is a rule
(exe, class, title or path) with a place: the index of a monitor and of a workspace, or
the name of a workspace. There are two kinds:
- an initial rule sends a window once, when komorebi first sees it: after that the window stays wherever you put it;
- a permanent rule sends the windows of the application there every time, so that a window you take away from that workspace goes back.
The windows are sent when a window opens or is focused, when the configuration is loaded, and when you ask for it: komorebi looks at the rules at each event about a window it manages, before it handles it. A window that opens is in a workspace only after its own event has been handled, so it is sent by the next event, which is the activation KWin reports a moment later.
Only the windows in view are looked at: the one on top of each container, and the floating windows. A window that is on its workspace already is left alone. A workspace that does not exist yet is made, with the ones before it. When the window is on the workspace in front, it leaves it and is hidden (it is put on the parking desktop, as the back of a stack is), and the workspace is tiled again without it; either way, it goes to the virtual desktop of its new workspace, so it is out of view until that workspace is shown, which brings it back and tiles it. A floating window that goes to another monitor is moved onto that monitor.
In komorebi.json
A workspace has workspace_rules and initial_workspace_rules, each a list of
rules like the ones in ignore_rules:
{
"monitors": [
{
"workspaces": [
{ "name": "web", "layout": "BSP" },
{
"name": "code",
"layout": "BSP",
"initial_workspace_rules": [
{ "kind": "Exe", "id": "kate", "matching_strategy": "Equals" }
],
"workspace_rules": [
{ "kind": "Class", "id": "org.kde.konsole", "matching_strategy": "Equals" }
]
}
]
}
]
}
The rules are made again from the file each time it is read, so a rule taken out of the file is
gone, and so are the ones komorebic added. The windows that are open are sent where the file
says when it has been read.
With komorebic
initial-workspace-rule and
workspace-rule take what the rule names (exe, class, title or
path), its text, and the index of the monitor and of the workspace;
initial-named-workspace-rule and
named-workspace-rule take the name of the workspace instead,
and add no rule when no workspace has the name. A rule given this way matches a title or a class
that starts or ends with what it names, and an executable or a path that is exactly what it names.
A rule that is there already is not added again.
komorebic initial-workspace-rule exe kate 0 1
komorebic workspace-rule class org.kde.konsole 0 1
komorebic named-workspace-rule exe thunderbird mail
enforce-workspace-rules forgets which windows the initial
rules have sent and looks at the rules again, so that every window of an application goes to the
workspace its initial rule gives. The three clear commands take rules away:
clear-workspace-rules by monitor and workspace index,
clear-named-workspace-rules by name, and
clear-all-workspace-rules all of them. The first two
also take away the rules of every other workspace of the monitor they are given, and of every
other monitor's workspace with the same index, because of how they pick the rules to keep. Which
rules the daemon has is in the workspace_rules of
komorebic global-state.