Workspace i is KWin's desktop i, and switching and moving by index came with the
workspaces. What a user binds keys to besides is the rest of komorebi's
workspace commands: going to the next or the previous workspace (or the next
empty one), back to the last one, adding and closing workspaces, showing one
index on every monitor, and setting the layout or the tiling of a workspace that
need not be in front. They are made of the same two operations, showing a
workspace and moving a container to one, so KWin keeps doing the showing and the
hiding.
A workspace gets a name, which focus-named-workspace, named-workspace-layout and
named-workspace-tiling find it by on any monitor; focusing a named workspace
focuses its monitor too, so focus_monitor comes with it. The name is komorebi's:
naming a workspace does not rename KWin's desktop. The query
focused-workspace-name answers with the name, or the index of a workspace that
has none.
The moves to a named workspace, and everything that addresses a monitor, are
moves between monitors in the window manager and come with more than one
monitor.
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.