Files
komorebi/docs/linux/example-configurations.md
T
LGUG2Z a7b78cc7e4 docs(linux): paths and links name the consolidated layout
The KDE docs were moved from komorebi-for-kde/ to docs/linux/ and the sources, nix files,
scripts and schemas to komorebi-linux/, nix/linux/, scripts/linux/ and schemas/linux/, so
every relative link that left docs/ (to sources, nix files, scripts, schemas, .envrc,
rust-toolchain.toml, the old CI file) was broken, and the text named the old paths.

Links were rewritten mechanically by resolving each broken target against the old
location and mapping it to the new one; link texts and code-span paths were updated to
the new paths (komorebi/src -> komorebi-linux/src, nix/ -> nix/linux/, scripts/ ->
scripts/linux/, docs/ -> docs/linux/, schema.json -> schemas/linux/schema.json). The
crate list of the README names komorebi-linux, komorebi-daemon and komorebi-version;
`cargo install --path komorebi` becomes komorebi-daemon; the comparison paragraph of
CONTRIBUTING.md says compare-gen.py is stale (it looks for the old sibling trees).

URLs of the old GitHub repositories are left as they are (a release decision).
COMPARE.md is left as it is (already marked stale).

Verified: a link checker over every markdown file (outside cli/, nix/, tools/, old-ci)
reports no broken link in docs/linux. Nothing was built.
2026-11-05 15:03:27 -08:00

260 lines
6.9 KiB
Markdown

# 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/linux/komorebi.example.json`](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](installation.md)), and by a key binding
file in the format of skhd, whkd or sxhkd ([Key bindings](usage/keybindings.md)); 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:
```json
{
"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](#key-bindings), where the daemon looks for them
([Quickstart and autostart](usage/quickstart-and-autostart.md)). Or put it there yourself,
`~/.config/komorebi/komorebi.json`, or give it to the daemon with `komorebic start --config`. [Configuration](usage/configuration.md) 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/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](usage/application-specific-configuration.md) 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
```text
+-------+-----+
| | |
| +--+--+
| | |--|
+-------+--+--+
```
#### Vertical Stack
```text
+-------+-----+
| | |
| +-----+
| | |
+-------+-----+
```
#### RightMainVerticalStack
```text
+-----+-------+
| | |
+-----+ |
| | |
+-----+-------+
```
#### Horizontal Stack
```text
+------+------+
| |
|------+------+
| | |
+------+------+
```
#### Columns
```text
+--+--+--+--+
| | | | |
| | | | |
| | | | |
+--+--+--+--+
```
#### Rows
If you have a vertical monitor, I recommend using this layout.
```text
+-----------+
|-----------|
|-----------|
|-----------|
+-----------+
```
#### Ultrawide Vertical Stack
If you have an ultrawide monitor, I recommend using this layout.
```text
+-----+-----------+-----+
| | | |
| | +-----+
| | | |
| | +-----+
| | | |
+-----+-----------+-----+
```
#### Grid
If you like the `grid` layout in [LeftWM](https://github.com/leftwm/leftwm-layouts) this is almost exactly the same!
The `grid` layout does not support resizing windows tiles.
```text
+-----+-----+ +---+---+---+ +---+---+---+ +---+---+---+
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | +---+
+-----+-----+ | +---+---+ +---+---+---+ +---+---| |
| | | | | | | | | | | | | +---+
| | | | | | | | | | | | | | |
+-----+-----+ +---+---+---+ +---+---+---+ +---+---+---+
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:
```nix
{
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:
```nix
{
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`](skhdrc.sample), [`whkdrc.sample`](whkdrc.sample) and
[`sxhkdrc.sample`](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:
```sh
mkdir -p ~/.config/komorebi
cp docs/skhdrc.sample ~/.config/komorebi/skhdrc
```