LGUG2Z
9cb26daf38
On NixOS the key bindings belong in the configuration, with the rest of
komorebi. services.komorebi.keybindings takes the format (skhd, whkd or sxhkd),
the bindings as text or as a file (exactly one of the two, asserted), the mode
(auto, engine or static; engine by default, as PlanMode::default() is),
chordTimeout (3000 ms), layout (us, the only one), strict and appAliases. skhd's
.load is refused by an assertion: the file it reads would not be in the store.
At build time the module runs komorebic hotkeys compile on the file in the
package komorebi-keybindings, whose share/kglobalaccel goes into the system
profile, where KWin finds the static shortcuts when the session starts. Its
diagnostics are in the build log and in diagnostics.txt, and strict passes
--strict, which fails the build on a warning or an error. execStart gains
--keybindings with the same store file, its format and mode, --chord-timeout and
an --app-alias per alias, so the daemon plans the file as the build did and runs
the bindings the build left to the engine. The unit already releases the keys
after the daemon stops.
The check keybindings-fixtures runs every file of the fixture corpus through
komorebic hotkeys compile --mode auto --dry-run, the command the module runs,
and diffs what it prints against nix/tests/keybindings.expected; it also checks
that docs/{skhdrc,whkdrc,sxhkdrc}.sample are the corpus's sample case.
nixos-module-eval gains the key binding scenarios: text, file, both, no format,
.load and a layout that is not us, and one with the typed config together with
key bindings, whose execStart has the checked file and then the keys. The corpus
gains the case vm, in the three formats: a binding a shortcut file can hold, and
one on the comma key, which X-KDE-Shortcuts cannot, so that the engine runs it
in auto mode. The VM suites vm-keys-skhd, vm-keys-whkd and vm-keys-sxhkd
configure the module with that case in their format and press both keys; they
share one script through the generator's script attribute.
For strict, nixos-module-eval has two scenarios with the same skhd text, which
has a line komorebic cannot read: strict = true and the default. Evaluation
never reads the key bindings, so the checks read the script of the build: with
strict it runs hotkeys compile --strict and exits 1 when that fails, without it
there is no --strict and the diagnostics are only printed to the build log. A
third check says the daemon gets the same command line either way. ARCHITECTURE
names them in the row for strict.
komorebic quickstart writes the sample skhdrc next to komorebi.json and
applications.json, from docs/skhdrc.sample, where the daemon and hotkeys compile
read it; the flake's source filter keeps that file for the build.
Docs: the user guide docs/usage/keybindings.md, the three sample files,
docs/example-configurations.md for KDE and NixOS, the options in
docs/installation.md, and the module's section of ARCHITECTURE. Whether the
engine or static shortcuts should be the default stays open in DESIGN: a static
shortcut took 233 ms to run its command at the median on KWin 6.8.1, the engine
3 ms, but only the static shortcut survives a dead daemon.
2.7 KiB
Quickstart and autostart
Quickstart
komorebic quickstart writes three example files into the config home
(~/.config/komorebi, or $KOMOREBI_CONFIG_HOME), which it makes if it has to:
komorebi.json, which isdocs/komorebi.example.json: eight workspaces on the first monitor, each with another layout, and some padding;applications.json, which iskomorebic/applications.json, the ruleskomorebi.jsonnames for the applications that need them;skhdrc, which isdocs/skhdrc.sample: the key bindings of the sample, in the format of skhd, which the daemon andkomorebic hotkeys compileread from there.
When a file is there already, quickstart asks before it writes over it, and leaves the file
alone unless the answer is y or yes. It prints the files it wrote, and then tells you to run
komorebic start.
komorebic quickstart
komorebic start
Starting komorebi with Plasma
On NixOS, the module starts komorebi with every Plasma session.
Elsewhere, komorebic enable-autostart writes an XDG autostart
entry, ~/.config/autostart/komorebi.desktop ($XDG_CONFIG_HOME/autostart), which Plasma runs at
login, after its workspace has started:
komorebic enable-autostart
komorebic enable-autostart --config ~/mine.json
The entry runs komorebi, or komorebi --config with the file --config names, as the session
finds komorebi on its PATH. komorebic disable-autostart takes
the entry away again, and says so when there is none.
Do not use both the module and the entry: the session bus gives its name to one komorebi, and the second exits.
Starting over with another file
komorebic replace-configuration makes the running daemon start
over from another komorebi.json:
komorebic replace-configuration ~/work.json
The daemon makes its window manager again from the file, as it does at start: it brings back
the windows it had hidden, the back of a stack, so that none is out of sight, loads the monitors
and the windows that are open from KWin, gives the monitors the entries of the file and tiles
them, and from then on watches the new file and not the one it had. It is not the same as
changing the file the daemon watches, which Configuration
describes: the windows that were in a workspace go where the new file puts them, not where they
were. A file that is not a komorebi.json is logged, and the daemon carries on as it was.