Files
komorebi/docs/example-configurations.md
T
LGUG2Z 9cb26daf38 build(nix): keybindings in the module
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.
2026-10-28 07:39:49 -07:00

6.9 KiB

Example configurations

komorebi, and tiling window managers in general, are very complex pieces of software. To make starting out easier, the repository has an example configuration, docs/komorebi.example.json, which is kept working: a test loads it with every change.

Besides komorebi.json, komorebi for KDE is configured by the NixOS module, which installs it and starts it with every Plasma session (Installing komorebi), and by a key binding file in the format of skhd, whkd or sxhkd (Key bindings); examples of both are further down.

komorebi.json

The example sets some defaults and gives the first monitor eight workspaces, each with a different layout. This page has the file as it is:

{
  "app_specific_configuration_path": "$HOME/.config/komorebi/applications.json",
  "cross_monitor_move_behaviour": "Insert",
  "default_workspace_padding": 15,
  "default_container_padding": 15,
  "border": true,
  "border_width": 6,
  "border_offset": 5,
  "floating_window_aspect_ratio": "Widescreen",
  "floating_layer_behaviour": "Float",
  "resize_delta": 100,
  "ignore_rules": [],
  "floating_applications": [],
  "manage_rules": [],
  "monitors": [
    {
      "workspaces": [
        {
          "name": "I",
          "layout": "BSP",
          "initial_workspace_rules": [
//            {
//              "kind": "Exe",
//              "id": "firefox",
//              "matching_strategy": "Equals"
//            }
          ]
        },
        {
          "name": "II",
          "layout": "VerticalStack"
        },
        {
          "name": "III",
          "layout": "HorizontalStack"
        },
        {
          "name": "IV",
          "layout": "UltrawideVerticalStack"
        },
        {
          "name": "V",
          "layout": "Rows"
        },
        {
          "name": "VI",
          "layout": "Grid"
        },
        {
          "name": "VII",
          "layout": "RightMainVerticalStack"
        },
        {
          "name": "VIII",
          "layout": "Scrolling"
        }
      ]
    }
  ]
}

komorebic quickstart writes it, the applications.json below and an skhdrc of sample key bindings, where the daemon looks for them (Quickstart and autostart). Or put it there yourself, ~/.config/komorebi/komorebi.json, or give it to the daemon with komorebic start --config. Configuration explains every key and where the daemon looks. The settings of a monitor with more than one entry in monitors, and of each workspace, are there too.

Application specific configuration

app_specific_configuration_path names a file of rules for the applications that need them, which the repository has a start of in komorebic/applications.json. komorebic quickstart puts a copy where the example says, ~/.config/komorebi/applications.json; a path with no file behind it is skipped. Application specific configuration explains the format.

Padding

While you can set the workspace padding (the space between the outer edges of the windows and the edge of the monitor) and the container padding (the space between each of the tiled windows) for each workspace on its own, you can also set a default for both of these values that applies to all workspaces, using default_workspace_padding and default_container_padding.

The floating layer

floating_layer_behaviour is Float in the example: a window that opens while a workspace is on its floating layer floats, centered, where the default is to tile it. A window that opens while the workspace is on its tiling layer is tiled either way.

Layouts

BSP

+-------+-----+
|       |     |
|       +--+--+
|       |  |--|
+-------+--+--+

Vertical Stack

+-------+-----+
|       |     |
|       +-----+
|       |     |
+-------+-----+

RightMainVerticalStack

+-----+-------+
|     |       |
+-----+       |
|     |       |
+-----+-------+

Horizontal Stack

+------+------+
|             |
|------+------+
|      |      |
+------+------+

Columns

+--+--+--+--+
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |
+--+--+--+--+

Rows

If you have a vertical monitor, I recommend using this layout.

+-----------+
|-----------|
|-----------|
|-----------|
+-----------+

Ultrawide Vertical Stack

If you have an ultrawide monitor, I recommend using this layout.

+-----+-----------+-----+
|     |           |     |
|     |           +-----+
|     |           |     |
|     |           +-----+
|     |           |     |
+-----+-----------+-----+

Grid

If you like the grid layout in LeftWM this is almost exactly the same!

The grid layout does not support resizing windows tiles.

+-----+-----+   +---+---+---+   +---+---+---+   +---+---+---+
|     |     |   |   |   |   |   |   |   |   |   |   |   |   |
|     |     |   |   |   |   |   |   |   |   |   |   |   +---+
+-----+-----+   |   +---+---+   +---+---+---+   +---+---|   |
|     |     |   |   |   |   |   |   |   |   |   |   |   +---+
|     |     |   |   |   |   |   |   |   |   |   |   |   |   |
+-----+-----+   +---+---+---+   +---+---+---+   +---+---+---+
  4 windows       5 windows       6 windows       7 windows

A NixOS configuration

The module and the sample key bindings of the repository, with every binding a static shortcut can be made one, and the engine for the rest:

{
  services.desktopManager.plasma6.enable = true;

  services.komorebi = {
    enable = true;
    keybindings = {
      format = "skhd";
      file = ./skhdrc;
      mode = "auto";
      # the names an skhdrc gives applications are those of macOS
      appAliases."Google Chrome" = [ "google-chrome" ];
    };
  };
}

The key bindings can also be written in the configuration itself:

{
  services.komorebi.keybindings = {
    format = "sxhkd";
    text = ''
      alt + {h,j,k,l}
          komorebic focus {left,down,up,right}
      alt + shift + {h,j,k,l}
          komorebic move {left,down,up,right}
    '';
  };
}

Key bindings

skhdrc.sample, whkdrc.sample and sxhkdrc.sample bind the same keys to the same komorebic commands in the three formats: focusing, moving, stacking and resizing windows, the layouts, and the workspaces. Each is a starting point for a file of your own, in the format you know. Their bindings are all plain ones, so with mode = "auto" every one of them is a static shortcut, and with the default mode, engine, the daemon runs every one.

Copy one to ~/.config/komorebi, where the daemon and komorebic hotkeys compile look for a key binding file when they are given none, to use it without NixOS:

mkdir -p ~/.config/komorebi
cp docs/skhdrc.sample ~/.config/komorebi/skhdrc