komorebi draws no border. KWin's KDE Rounded Corners effect does, outside each
window in the gap the layout leaves, and komorebi says how it looks. The window
manager describes a Look (a border with a width, a radius and two colors) and
asks the backend for it with Backend::apply_look after every event, message and
retile. The backend answers whether borders are being drawn, and the layout
leaves room around the windows only while they are: a border with no effect to
draw it takes none.
The KWin backend writes the effect's settings into the user's kwinrc, with every
inner outline off (the effect's default draws one over the title bar), loads the
effect when borders are on and has it read them again. It unloads the effect and
puts the user's settings back when the borders go or komorebi exits. The module
installs the effect (effects.borders), which is built to stay unloaded until
komorebi asks, and vm-look reads the pixels around two windows in a real
session.
The session library of the VM tests also waits for the panel of the Plasma shell
now: a window komorebi tiles before the panel is made is tiled under it, which
hides the bottom of its border from a screenshot.
Kde.wait_for_panel_room waits until the daemon's work area is not the whole of
its monitor, which is the daemon having learned that the panel takes room, and
vm-look calls it where the daemon starts, before the windows open. The shell
makes its panel and KWin takes room for it a while later, which the daemon
learns of up to a second after, so a daemon that tiles in between puts the
windows under the panel and tiles them again, and a screenshot taken between the
two shows frames as high as the screen. It is a wait and not a check, since a
session that is too slow, as TCG often is, may never take the room.
komorebic gets border, border-width and border-offset, and visible-windows.
komorebi.json takes the same settings as border, border_width and border_offset,
and border_radius, which has no command. The module warns when config asks for
borders and the effect is not installed.
A workspace rule sends the windows of an application to a workspace: an initial
rule once, when komorebi first sees the window, and a permanent rule every time,
so that a window the user takes away goes back. A rule is a rule on the window's
executable, class, title or path, with a monitor and a workspace index, or the
name of a workspace. It comes from komorebi.json (workspace_rules and
initial_workspace_rules of a workspace, made again from the file each time it is
read) or from komorebic (workspace-rule, initial-workspace-rule, their named
forms, and the commands that clear and enforce them).
The window manager looks at the rules before it handles each event about a
window it manages, and again when the configuration is loaded, so the windows
that were open when the daemon started are sent too. A window that leaves the
workspace in front is taken out of the layout and hidden, as the back of a stack
is, and it is put on the desktop of its new workspace, which is what it comes
back to and is tiled on when that workspace is shown. A window that moves
between workspaces that are not in front is put on the desktop of its new
workspace as well. A floating window that goes to another monitor is moved onto
it, and a workspace that does not exist yet is made.
Rules for particular applications can be kept in files of their own,
applications.json, which komorebi.json names with
app_specific_configuration_path: one path or a list. The ignore, manage and
floating rules of every application in a file are added to the lists the
configuration's own rules go in, so a file can be shared or kept apart from the
settings.
A path with no file behind it is skipped with a warning, since one komorebi.json
is meant to work on every platform and may name a file that only another
platform has; a file that is there and is not an applications.json is an error.
The titleless and tabbed rules of other platforms are read and do nothing.
komorebic/applications.json is a start for Plasma: it floats the calculators,
the screenshot tool, the authentication dialog and System Settings. A test opens
the windows it names.
The daemon takes its settings from a komorebi.json: the file --config names, or
the one in the config home ($KOMOREBI_CONFIG_HOME, else ~/.config/komorebi).
Without a file it runs on its defaults, as before.
StaticConfig reads the file in three steps, because the monitors are known only
after the backend has been asked. preload makes the window manager and applies
the settings that are process-wide, postload gives each monitor and workspace
the entry of its place (by the index display_index_preferences gives a monitor's
serial number id, else in order), and main asks KWin for a desktop for each
workspace the file lists. A watcher on the file sends the daemon a
ReloadStaticConfiguration about two seconds after it changes, whether an editor
wrote the file in place or renamed a new one over it, and a file that does not
parse changes nothing.
A workspace can change its layout, its work area offset and its layout options
with the number of its containers, from the file or with komorebic
(workspace-layout-rule, its named form and the two that clear), and
layout_defaults gives every workspace of a layout the options it sets none of.
One file is meant to serve every platform, so a key that does nothing on Plasma
is accepted and ignored. config_parity checks the example and the files of other
platforms; the keys of features that are not in yet are listed there, and the
test fails when a list names a key that is read.
The file also sets what the stacks, the float override, the floating layer and
monocle set while the daemon runs: window_container_behaviour, with its rules by
container count in a workspace, float_override, float_override_placement,
floating_layer_behaviour (for a monitor and a workspace too),
floating_layer_placement and monocle_focus_behaviour. Their features come before
this commit, but a file to put the keys in does not, so they are part of this
one.
komorebic gains configuration, generate-static-config and start --config. The
NixOS module gets configFile, which the unit gives the daemon as --config.
LGUG2Z