The daemon takes its settings from a komorebi.json: the file --config names, or
the one in the config home ($KOMOREBI_CONFIG_HOME, else ~/.config/komorebi).
Without a file it runs on its defaults, as before.
StaticConfig reads the file in three steps, because the monitors are known only
after the backend has been asked. preload makes the window manager and applies
the settings that are process-wide, postload gives each monitor and workspace
the entry of its place (by the index display_index_preferences gives a monitor's
serial number id, else in order), and main asks KWin for a desktop for each
workspace the file lists. A watcher on the file sends the daemon a
ReloadStaticConfiguration about two seconds after it changes, whether an editor
wrote the file in place or renamed a new one over it, and a file that does not
parse changes nothing.
A workspace can change its layout, its work area offset and its layout options
with the number of its containers, from the file or with komorebic
(workspace-layout-rule, its named form and the two that clear), and
layout_defaults gives every workspace of a layout the options it sets none of.
One file is meant to serve every platform, so a key that does nothing on Plasma
is accepted and ignored. config_parity checks the example and the files of other
platforms; the keys of features that are not in yet are listed there, and the
test fails when a list names a key that is read.
The file also sets what the stacks, the float override, the floating layer and
monocle set while the daemon runs: window_container_behaviour, with its rules by
container count in a workspace, float_override, float_override_placement,
floating_layer_behaviour (for a monitor and a workspace too),
floating_layer_placement and monocle_focus_behaviour. Their features come before
this commit, but a file to put the keys in does not, so they are part of this
one.
komorebic gains configuration, generate-static-config and start --config. The
NixOS module gets configFile, which the unit gives the daemon as --config.
A workspace could show its windows only side by side. Monocle gives one
container the whole work area: the focused container is taken out of the
workspace's containers, so the layout gives no container a tile, and the next
tiling puts its window on the work area less the padding. Turning it off puts
the container back at the index it came from, and the tiles come back as they
were resized: the container keeps its resize adjustment, and the workspace does
not shorten the list of adjustments while a monocle is on.
The windows of the other containers are hidden on the parking desktop, as the
windows behind the front one of a stack are, and the front window of each is
shown again when the monocle is turned off or the window in monocle closes. A
stack in monocle stays a stack.
`komorebic toggle-monocle` turns it on and off. What focusing in a direction
does meanwhile is set with `monocle-focus-behaviour` or switched with
`toggle-monocle-focus-behaviour`: with `cycle` the monocle goes to the previous
or the next container, with `no-op`, the default, no container is on any side
and the focus falls through to the monitor on that side, where the monocle
window of its workspace, if it has one, is given the focus, and the command
fails where there is no monitor. A container that is moved to a monitor or sent
to a workspace in monocle turns that monocle off first. `cycle-focus` always
carries the monocle along. Giving the focus to another window gives it back to
the monocle window, so that it stays in front. `move` and `cycle-move` are
refused and `toggle-float` is ignored while a window is in monocle, since the
focused container is not the window in front. The monocle container is in the
state, with the index it goes back to, and a window in it that closes takes the
monocle with it.
komorebi/tests/monocle.rs drives it against the fake desktop, with one monitor
and with two. vm-core-e2e checks in a real KWin that the focused window fills
the work area, that the state has the monocle container, that toggling back
restores the tile, that the cycle behavior gives another window the work area,
and that the windows behind a monocle are parked, which a clean stop and the
next start after a crash put right; vm-stacks checks a monocle over a stack; the
vm-commands sweep runs the new commands.