The first tile of a layout is its largest, and the place for the window being
worked on. `komorebic promote` moves the focused window there, with the windows
that were before it each moving one tile on; `promote-swap` swaps it with the
window that has the first tile, and from the first tile swaps it back with the
window it was last swapped with; `promote-window left|right|up|down` promotes
the window on that side of the focused one; and `promote-focus` gives the focus
to the first tile and moves nothing.
The grid layout has no largest tile, so the four do nothing there.
The vm-commands sweep gains the four.
`komorebic resize-edge left|right|up|down increase|decrease` moves one edge of
the focused tile, and `resize-axis` both edges along an axis, by the delta that
`resize-delta` sets (50 pixels to start with; komorebi-layouts moves an edge by
half of it). The neighbors give up the room.
A resize is an adjustment of the container's tile that the workspace keeps, one
per container, and that the layout applies whenever it tiles. Before each
tiling, the workspace clears the parts its layout cannot apply, such as the
height of a column. No tile may end up narrower or shorter than a tenth of the
work area, or than it already is: a resize that would make one so is granted as
far as it can go, not dropped.
`retile` drops the adjustments, and the `RetileWithResizeDimensions` message
tiles with them. `save-resize` and `load-resize` write them to a file and read
them back, and `quick-save-resize` and `quick-load-resize` do the same with one
file in the daemon's temporary directory.
The vm-commands sweep gains every resize command, and the saving and loading.
`komorebic layout-ratios --columns ... --rows ...` sets the share of the work
area the first columns and rows of the focused workspace's layout take, and
`scrolling-layout-columns N` how many columns of the scrolling layout are in
view. Both are layout options of the workspace, which komorebi-layouts reads.
The scrolling layout is a strip of columns that runs past the edges of the work
area, so its tiles are not clamped to it: the windows of the columns out of view
are off the screen. When a window of a scrolling workspace gets the focus, the
workspace is tiled after the focused container changed, which scrolls the strip
to it.
KWin moves a window anywhere, but keeps 100 pixels of a window it resizes on an
output once the client has drawn at the new size, which pulls the columns out of
view back onto the screen. The bridge remembers the position it was asked for,
for a second, and asks again for the position alone when KWin moved the window
elsewhere, three times at most.
komorebi-layouts compiles `Rect::percentage_within_horizontal_bounds` only with
its darwin feature, which this repository does not enable, so the workspace has
its own copy of it.
A new VM suite, vm-scrolling, after the spike's m2-scrolling script, checks in a
real KWin that the columns out of view stay where komorebi put them and that the
strip follows `komorebic focus`; vm-commands sweeps the two new commands.
Every workspace started in BSP and stayed there. `komorebic change-layout` gives
the focused workspace one of the layouts of komorebi-layouts, `cycle-layout
next|previous` steps through them, and `flip-layout` mirrors the tiles along an
axis, on top of the flip there is. A flip mirrors the tiles, not the order of
the containers, and the directions of focus and move are flipped with it, so
`focus left` still goes to the tile on the left.
`toggle-tiling` turns the tiling of the focused workspace off and on: while it
is off, no window of the workspace is moved, and the windows that open are taken
in and tiled once it is on again.
`preselect-direction` reserves the place on one side of the focused window for
the next window: an empty container holds it, the layout gives it a tile, and
the next window takes it. `cancel-preselect` gives it back.
A new VM suite, vm-commands, after the spike's m8 script, runs every layout with
five, three, two and one windows against a real KWin with two outputs, and then
every komorebic command there is, checking after each that the daemon is alive,
answers, and has every window KWin has, and that KWin has the windows where the
daemon asked. Every command that comes later adds its line to that sweep.
With the focus moving, the next thing a key has to do is move the focused
window. `komorebic move left|right|up|down` swaps the focused container with the
one whose tile is on that side, as the layout sees it, and `komorebic cycle-move
next|previous` with the next or the previous one in the workspace's order. The
workspace is tiled again, the window that moved keeps the focus, and the pointer
follows it.
The swap goes through the lockable sequence, so a lock stays with its index: the
container moved onto a locked index is locked in its place.
Moving towards a side with no window fails and moves nothing. Moving into the
next monitor comes with more than one monitor, and the floating layer's own move
with the floating layer.
The VM test moves a window in a real KWin and back, and checks that KWin has
every window where komorebi asked.
A tiling window manager is driven from the keyboard, and the first thing a key
has to do is move the focus. `komorebic focus left|right|up|down` gives the
focus to the window whose tile is on that side of the focused one, as the layout
sees it, and `komorebic cycle-focus next|previous` to the next or the previous
window in the workspace's order, wrapping around. Neither moves a window: the
focus changes, the tiles stay.
The pointer follows the focus, through KWin's "Move Mouse to Focus", unless
`mouse-follows-focus disable` (or `toggle-mouse-follows-focus`) says not to.
Focusing towards a side with no window fails and changes nothing. Crossing into
the next monitor, as komorebi does on the other platforms, comes with more than
one monitor; so do eager-focus and the parts that depend on the monocle,
maximized and floating windows.
The VM test now drives the focus with komorebic in a real KWin and checks that
KWin and komorebi agree on the focused window afterwards.
On NixOS, running komorebi should take one flake input and one module line. The
flake exports `services.komorebi` as nixosModules.default (and .komorebi). It
adds the flake's overlay, which gains komorebi-full, installs komorebi and
komorebic, and runs the daemon in every Plasma session as a systemd user unit,
wanted by plasma-workspace.target and ordered after plasma-core.target, which
Plasma orders after KWin. systemd starts a daemon that fails again; the exit
status of a SIGTERM (130) counts as success, so a stopped unit is not failed.
The unit's PATH is the one a terminal in the session has, instead of the few
store paths NixOS gives a unit.
The options are enable, package, logLevel and a read-only execStart, the command
line the unit runs. There is no configFile: the daemon reads no configuration
file yet, and an option that linked one would do nothing.
nixos-module-eval evaluates seven scenarios as real NixOS systems and checks
their assertions, the unit and execStart, with builtins.tryEval for the two that
must not evaluate. Nothing in it builds a Linux package, so it runs on a Mac as
well.
The VM nodes import the module, so every suite runs komorebi as the module
installs it. The headless node's komorebi@NAME runs execStart, which has
--log-level, so the nodes set logLevel to debug and the suites stop passing it;
latency, which times the daemon, keeps the default level. The session node
starts the module's unit at login; render-smoke turns it off, since a tiled
terminal would cover the desktop it looks at. A new fast suite, vm-module, logs
in to Plasma and checks that the unit runs the daemon with the module's log
level and PATH, that a window opened in the session is tiled, that a killed
daemon is started again, and that a stop is not a failure.
docs/installation.md covers NixOS first, and building from source on other
distributions. There is no binary cache: the Komorebi license does not allow
third parties to redistribute binaries.
A program such as a status bar has to follow the window manager, and so far it
could only ask: komorebi on Windows and on macOS sends notifications for that.
The daemon now keeps subscribers, each a Unix socket in its data directory that
a program listens on, and after each event and each message it handles, it
connects to every subscriber and writes the event or the message with the state
after it.
A subscriber can ask to be sent only what changed the state; a window that is
shown and a new subscription are always sent, so a subscriber has the state as
soon as it subscribes. A subscriber that cannot be connected to is dropped with
its socket file and not tried again, and a stopping daemon closes an empty
connection to each one.
komorebic gains subscribe-socket and unsubscribe-socket, and komorebi-client
subscribe and subscribe_with_options, which bind the socket and subscribe. The
tests subscribe through real sockets against the fake desktop: a shown window is
sent with the state that has it, a subscriber that filters is not sent a
question that changed nothing, and one that is gone is dropped.
The daemon answers on its socket, but a person has no way to write a message on
it. komorebic is that way: each subcommand that asks something of the daemon is
one message, sent with komorebi-client, and a question's answer is printed.
komorebic is a separate program because the daemon takes no input but its
socket, so a key binding, a script and a terminal all drive it the same way.
It has what the daemon can answer so far: state, monitor-information, query,
retile and stop. Around them, start runs the komorebi on the PATH in the
background and passes it what follows a --, such as --fake-backend to try it
without a compositor; log follows the daemon's log, which the daemon now writes
to a file a day in LOG_DIR as well as to stdout; data-directory shows where the
socket is; completions prints a shell completion script. The hidden docgen
writes each subcommand's help to docs/cli, in fences that name their language
and wrapped at 100 columns whatever the width of the terminal, so that the pages
are the same wherever they are generated; just docgen runs it.
The user guide starts here: docs/index.md for KDE Plasma, and a page on running
komorebi. tests/cli.rs runs each subcommand against a socket the test serves in
place of the daemon. In the VM tests the guests get komorebic next to the
daemon, and vm-core-e2e reads the daemon's state with it (the windows it
manages, the one it focuses, after KWin restarts too) and stops it with
komorebic stop, which unloads the bridge and removes the socket.
In the VM test library, Kde.state asks again, a second (times the scale) after
an empty answer or a failed command, up to 10 times. The daemon drops a query
when it cannot take hold of the window manager within a second, and komorebic
then prints an empty line and succeeds; komorebic itself gives the daemon a
second to answer and fails when that is not enough. A daemon busy with the first
windows does either on a machine that is loaded or slow, and a suite that polled
the state died on JSONDecodeError. An answer that is not JSON still fails at
once.
LGUG2Z