A port that cannot start with a case's rules, or orders its windows
otherwise, is recorded as a known failure for that case, and the other
cases run on. kfw does not accept the place as a JSON number, so
BEHAVIOUR.md lists the case as a known failure there.
Where a window that opens goes, from the placement rules of the
config: none, Primary, a number as a number and as text, and rules by
title for the first and the last place. restart_with starts the daemon
afresh with a komorebi.json the scenario gives. KdePlatform.spawn
quotes the title, which a title with spaces needs. core-e2e runs it as
section 12a.
Checks.known_failure records a check that fails for a reason that is
to be followed up on: the suite does not fail, the totals say how many
known failures there are, and one that holds fails the suite so the
marker goes. unknown_monitor takes the reason, and core-e2e runs it
last, because the window it loses stays lost. BEHAVIOUR.md says so.
After clear-all-workspace-rules a window that the old rules matched
opens on the workspace in view and stays there. The first window of
that title is closed before the next opens, because the title is how
a window is named on both ports.
The daemon stops, every window stays, and a daemon that starts again
manages the windows that were in view, tiled inside the work area and
clear of each other, and also a window opened afterwards. The fake
platform learns to stop and to start with no memory of workspaces.
core-e2e runs it before its final stop.
kfw declares the subcommand with arg_required_else_help, so without an
argument it prints help and exits 2, although the option has a default.
kfde accepts the same option, so the sweep passes it explicitly:
--implementation windows, the default on both ports.
The scenario sends the focused window to monitor 7 with send-to-monitor and
move-to-monitor, which no display has, and checks that the daemon still
manages every window. A port may refuse or ignore the command, but a window
that was managed has to stay so: one that is not is left on the screen with
nothing tiling it.
It found a bug in both ports. kfw managed one window fewer than the OS had
afterwards (seen by hand on a Windows guest), and kfde failed it in
core-e2e on a real KWin: move_container_to_monitor takes the focused
container out of its workspace before it looks the monitor up, so the
error for a monitor that is not there comes after the container is gone.
It is not fixed, so the scenario is not in core-e2e, which would fail;
BEHAVIOUR.md has the finding. Its unit tests run it against a fake that
loses the window and one that ignores the command.
The sweep has commands that name the second monitor, send-to-monitor 1 and
the ones after it, so it needs two displays. The KDE suite runs with two
outputs and never noticed. On Windows, with one display, the first run of
the sweep reported that after send-to-monitor 1 kfw managed one window
fewer than the OS had, and every command after it was reported unhealthy;
whether that is kfw losing a window sent to a monitor that does not exist
has not been confirmed by hand. The sweep now plugs in a display first if
the platform has one, and a fake with one display shows it does.
commands is every layout, a sweep of 216 commands and the commands that
only print, each of which must be understood and leave the daemon healthy
(it answers state and manages the windows the OS has). A command the port
lacks, which komorebic says with 'unrecognized subcommand', is skipped with
its name, which is what a behaviour matrix is made of: Checks.skip records
it and finish prints how many. The commands suite runs it instead of its
own copy of the list: 270 checks pass, none skipped.
rules gives the daemon an initial rule, a rule that is not, and an ignore
rule, by title, and checks where each window goes. It found that
enforce-workspace-rules applies initial rules again on purpose, so the
scenario asks whether the daemon sends the window back on its own.
hotplug unplugs a display, plugs one in and sends a window to it, and
starts by plugging one in if the platform has only one. Platform gets
displays, add_display and remove_display, and KdePlatform does them with
kscreen-doctor. The hotplug suite runs it: 34 checks pass.
core-e2e runs rules after the others, then leaves a window for the stop to
leave behind: 130 checks pass on KVM. One run failed the check that the
daemon had exited after komorebic stop and the next did not; the cause is
not known, and the suite now prints the unit's status when it happens.
Snapshot.workspace_of tells which workspace has a window.
monocle toggles monocle on the focused window and checks that it fills the
work area up to the layout's padding, that the state has it as the monocle
container, that every other window is put away, that it keeps the focus,
and that toggling back puts every window in view on the tile it had.
closing closes a window and checks that the OS has no frame for it, that
the daemon manages one window fewer, and that the windows left in view
take more room between them, inside the work area and clear of each other.
Platform.close closes a window as its button would; KdePlatform does it
with kdotool. The fake daemon models monocle and closing, and its
os_window now knows the workspace a window is on, which the workspaces
scenario had passed without. core-e2e runs both: 120 checks pass on KVM.
Platform.has says whether a platform can do what a scenario needs, and
Platform.pointer is a Pointer (move, down, up, drag) where it has one;
KdePlatform takes the pointer of a session node. scenarios.resize drags the
edge two tiles share by 60 pixels and checks that the tiles that end at the
edge are that much wider, the ones that start after it start that much
later and end where they did, nothing moves up or down, and tiles that do
not touch the edge are where they were. A platform with no pointer skips
it, and says so.
The fake daemon has a pointer that moves an edge. The scenario runs on KDE
at the end of drag-resize: 19 checks pass on KVM. Its first run failed one
check that was the scenario's: both tiles of a BSP column share the dragged
edge, and the check took the second for one that had not moved.
core-e2e writes the komorebic state of kfde, with three tiled windows and
with one stacked onto another, into its output, and the files are kept in
tests/fixtures beside kfw's three, recorded from a Windows guest (tiled,
stacked, one window floated). test_recorded.py reads all five with the
same checks: three containers of one window, a layout rectangle for each
inside the work area, each window where its container's rectangle is up to
a terminal cell (foot rounds to cells, kfw's test window does not), and a
stack that is a container of two whose focused window is the one the ring
names. Nothing in the parser had to change; the checks passed on the first
real kfw state.
The scenes written from the serializers stay for the shapes no run has
recorded. The sync script copies the fixtures too. The workspaces scenario
prints which windows are in view after the switch: one run of core-e2e
failed that check and passed on the next, and the log did not say which
window had been in view.
scripts/sync-e2e-core copies komorebi_vm.core and the unit tests that
belong to it into another directory, and --check says whether the copy is
in step, so that kfw's Windows platform can be written against the code it
will run with while the move is not made. This repository is the source
until the move, and the script goes with it.
Two of those tests imported Rect and Checks from komorebi_vm, which pulls
in the KDE half; they import them from komorebi_vm.core now. The copy
passes its 25 tests in a directory with nothing but pytest and Pillow.
latency measured a p95 of 128.9 ms against its 100 ms times scale on the
WSL2 machine, under nested KVM with nothing else running, where x86-1 had
passed it at scale 1. Every Linux host is no faster than a Mac to the
suites that time the daemon, so scale is 1.5 on all of them: latency
passes at it with a p95 of 132.4 ms against 150 ms. The run-to-run
difference (p50 46.0 ms, then 70.0) is as large as the margin left, which
PLATFORM.md says.
PLATFORM.md records the wall times of the suites on this machine. All 33
were run there after the library was split: 32 passed at scale 1, and
latency is the one that failed. The other 32 were not rerun at 1.5, which
changes their derivations.
workspaces sends the focused window to workspace 1, checks that it is put
away and that the daemon has it there while the others stay in view,
switches to workspace 1 and checks that only that window is in view and has
the focus, and switches back.
hidden now says a window is out of sight for any reason the daemon has: on
KDE that is the parking desktop and also a desktop that is not the one in
view. Snapshot's workspace, containers and focused_title take the focused
workspace when none is given, and the fake daemon has two workspaces. The
scenario passes in core-e2e on KVM: 106 checks.
hidden says that a window exists but the daemon has put it away: the others
of a stack, here, and later those of another workspace or behind a monocle.
It is a window on the parking desktop on KDE and will be a cloaked one on
Windows. scenarios.stacks stacks the focused window onto its neighbor,
cycles the stack, checks that the window in view has the focus and fills
the tile the first had, and takes the stack apart.
The scenario's fake daemon now models stacks. Running it on KDE found a bug
in Snapshot: focused_title took the first window of the focused container,
and a stack's focused window is the one its ring names. Snapshot keeps that
index now. core-e2e runs the scenario after the others: 98 checks pass on
KVM.
focus moves the focus with focus and cycle-focus and checks that the OS and
the daemon's state agree on the window that has it and that no window moved.
moving swaps the focused window with its neighbor with move and puts every
window back with cycle-move, and checks that the focus stays with it. Both
read the windows through the Platform, so they are what kfw's suite will
run.
Their unit tests run against a fake daemon that follows the commands over
three tiles, and against two that do not (a move that moves nothing, a move
that loses the focus). core-e2e runs them after tiling on KDE: 85 checks
pass on KVM.
KdePlatform is a Kde session seen through the neutral vocabulary: kdotool
for the OS's frames, foot for clients, the cell of its font as the
tolerance. The core-e2e suite runs scenarios.tiling through it as a new
section, so that the scenario that will run on Windows is checked on the
one platform that works; the suite's own sections are unchanged. It passes
on KVM (74 checks) on the WSL2 machine.
A scenario drives the daemon and looks at the desktop only through a
Platform: start the daemon, komorebic, state as a Snapshot, spawn a window,
os_window (the OS's own account of its frame, which is the oracle: the
daemon's state is what is under test), work_area, activate and screenshot.
Only what a scenario uses is there; a method is added with the first
scenario that needs it.
scenarios.tiling opens windows and checks, against the OS's frames, that
each is where the layout says, inside the work area and clear of the
others. Its tests run it against a fake platform that tiles correctly and
against two that do not.
komorebic state prints a different JSON on kfde and on kfw: a window is
{id, rect, details} on one and {hwnd, title, exe, class, rect} on the
other, and a monitor and the state itself have fields the other lacks.
core.snapshot.parse reads either into monitors, workspaces, containers and
windows with the same names, keeping what only one has in Snapshot.extra,
so that a scenario does not have to care which port it runs on.
The fixtures in its tests are written from the two serializers, not
recorded; they are replaced by recorded states once a run on each port
exists.
Checks, Rect and the pixel helpers depend on no compositor. They move to
komorebi_vm.core, which may not import komorebi_vm.kde, so that the package
can go to the Windows port unchanged. komorebi_vm re-exports them and no
suite changes. This is the first step of the cross-platform e2e plan.
On a host whose GPU can encode H.264 (a Windows driver through d3d12 on WSL 2 does), KRDP in
the demo guest encoded on the guest's CPUs. The host side was fine (vainfo on the host lists
H.264 and HEVC EncSlice), and virgl can pass a guest's VA-API video to it, but a chain of seven
problems stood between the two. Each is a patch, and the guest takes them all:
QEMU (nix/dev/qemu-virgl-video.patch)
QEMU never asks virglrenderer for video: virglrenderer turns it on only for an embedder that
passes VIRGL_RENDERER_USE_VIDEO and a get_drm_fd callback to open the host's video device on.
The flag is defined only with VIRGL_RENDERER_UNSTABLE_APIS, which the build sets.
virglrenderer 1.3.0, four patches in this order
virglrenderer-chroma-format.patch
the guest's Mesa and virglrenderer number the chroma format of a codec differently: 4:2:0
was read as 4:2:2, and the host's encoder refused every codec it was asked for
virglrenderer-video-memory-upload.patch
the d3d12 driver has no dma-bufs: vaExportSurfaceHandle fails, nothing was uploaded and
the encoder returned an empty bitstream. The planes of the guest's picture are read back
(glReadPixels) and written to the surface through a derived image (vaDeriveImage, with
vaCreateImage and vaPutImage as a fallback)
virglrenderer-h264-packed-sps.patch
Mesa's VA-API takes the level of the stream from a packed SPS, which virglrenderer never
sent: level 0 reached UNREACHABLE in the d3d12 encoder and crashed QEMU
virglrenderer-ubo0-constants.patch
a constant buffer 0 bound as a buffer was never read by the shader, so the colour matrix
of an RGB to YUV conversion was zero and the picture was a solid green
Mesa 26.2.5 in the guest, two patches (hardware.graphics.package)
mesa-virgl-rgb-yuv-csc.patch
the graphics compositor never loaded an RGB to YUV matrix, and multiplied by the YUV to
RGB one of its initial state
mesa-virgl-fence-leak.patch
a surface kept the out-fence (a sync_file) of its last flush and the next flush stored a
new one over it: one file descriptor leaked per converted frame, 44 a second under motion,
and KRDP froze when it reached the limit of 1024, about 28 seconds in
KRDP (krdp.nix) asks for H264Baseline and the guest's driver lists Main and High, so ffmpeg's
h264_vaapi found no profile it could use: it is built with H264Main.
What was checked: a luma ramp and a colour-bar pattern encoded through the guest to the 4090
decode to the right values; the real desktop shows over RDP in Windows' own client with the
right colours; under es2gears motion the descriptors of krdpserver stay flat (3 sync_file, 78
of 1024) where they were 949 of 1024 after 28 seconds.
run-kde sets what the host needs for Mesa and for virglrenderer's libva to find the Windows
driver, on WSL 2 with the GPU on and unless it is set already: GALLIUM_DRIVER=d3d12,
LD_LIBRARY_PATH with /usr/lib/wsl/lib first, LIBVA_DRIVER_NAME=d3d12 and LIBVA_DRIVERS_PATH
(/run/opengl-driver/lib/dri, for the d3d12 video driver, which it looks for). --doctor checks
for the libraries and for that driver, and the tests have a scenario for each.
Known: the software decoder warns "illegal short term buffer state detected" on the stream; the
d3d12 encoder writes Constrained Baseline whatever profile is asked for. There is no binary
cache: the first run builds QEMU and Mesa, which takes about 20 minutes. QEMU, virglrenderer and
Mesa are the runner's and the guest's only, and the VM suites build the Mesa as well.
Not measured yet: whether it is smoother than the CPU encoder under the same load.
The guide for the one command: docs/trying-it.md says what a machine needs to
run the demo guest, with the lines of .wslconfig and of the NixOS-WSL
configuration for Windows 11, how to check it with `run-kde --doctor`, what the
command does and shows, the key bindings to try, how the GPU path is chosen, how
to open Windows' own RDP client, how long the first run takes (measured on a
machine with 32 cores and an empty store, by number of cores, with an estimate
for a WSL 2 machine and its caveats), how to start again, how to work on
komorebi in the guest, and what to do when something is wrong, by symptom. It
ends with what was run and what was not: nothing has been run on WSL 2 yet. The
README has a section and a link, and the user guide index a line.
DESIGN.md has four entries. Two record what I decided and want: the QEMU window
first and RDP second, and the GPU wherever the host has one. Two say that a
reason was not written down, for QEMU with KVM and not Hyper-V and for sharing
the password by a directory, and what is known that bears on each; the password
entry also says why a password is made for each user. PLATFORM.md has a section
for WSL 2 with what the command expects, a table of the probe results still to
be recorded (KVM, display, GPU, RDP, resources, virtiofs), and what is known of
virtiofsd without WSL 2.
The demo guest is what the command `run-kde` starts, so it should not stop
working between the times somebody runs it by hand. The suite `run-kde` puts the
guest module, nix/dev/run-kde.nix, on the session node, as the rdp suite does
with krdp.nix, and checks what only a booted session can say: the demo opens two
Konsole windows, Kate and Dolphin and komorebi tiles them clear of the panel,
the cheat sheet is a window that is not a tile, what it shows of `komorebic
check` has no error, and KWin says what it draws with.
The node makes the directory the host shares as the guest finds it once it has
mounted it: owned by a user the guest does not have, with a password and a
public key in it. The suite checks that the guest takes them as root before the
login, that ssh lets in that key and no other, that KRDP starts by itself and
listens, and that a client with the password is let in and shows the display.
The client of those RDP checks moves from the rdp suite into the library as
RdpClient, with unit tests against the fake machine, so that both suites run the
same checks; the machine protocol gains copy_from_machine for it.
Starting the demo guest by hand takes a build, a state directory, a password, a
key, the sizes of the machine and the right arguments for its display, and a
mistake shows up as an error from QEMU a minute later. `run-kde` does all of it:
`nix run .#run-kde` (or `just run-kde`) checks the machine, builds the guest
when its runner is not in the store, with the build log shown, makes the state
directory with a sparse disk, a random RDP password and an ssh key (all mode
0600, none of it in the Nix store), and starts the runner with KVM, the memory
and cores the machine has, the repository at /repo, and the state directory at
/run/run-kde. It prints a banner with the RDP address and password, the ssh
command, how to quit, and which graphics mode it chose and why.
`--doctor` prints every prerequisite as a tick, a cross or a warning with the
exact fix: WSL 2 or not, KVM and its group, nested virtualization, virtiofs (a
virtiofsd started as the user with the options of the guest's runner must serve
a directory, since the guest mounts its /nix/store through one; /dev/fuse is
only a warning), memory, disk, WSLg, Windows interop, the GPU and the OpenGL of
the host, and the lines of .wslconfig. It exits with 1 when something is a
cross, which includes a missing KVM unless `--tcg` allows software emulation.
The GPU is used when the display is a window, the host has a GPU device and its
OpenGL is not llvmpipe, and `--gpu on|off` overrides it; on WSL 2, `--rdp` opens
mstsc with a credential that lasts as long as the run.
The script reads the machine through variables, so `--dry-run` and `--doctor`
can be tested against machines that a check makes up: `run-kde-dry-run` and
`run-kde-doctor` compare their output with the texts in nix/tests/run-kde, and
the package, which shellchecks the script when it is built, is a check too.
A person who wants to see komorebi tile windows should not have to configure a
machine first. `run-kde-x86_64` and `run-kde-aarch64` are the session guest with
a demo on it: the NixOS module configures komorebi from a typed `config` (eight
workspaces, borders, animation) and the sample skhd bindings, and at login the
guest opens two Konsole windows, Kate and Dolphin, which komorebi tiles, and a
cheat sheet window that it leaves alone, with the key bindings, `komorebic`
commands to try, what KWin draws with, and the output of `komorebic check`.
The closure is the same for everyone. No password or key is in it: the host
shares a directory, which the guest mounts at /run/run-kde, and a unit copies
the RDP password and the ssh public key from it, since the files can belong to a
user of the host who is not the guest user. krdp.nix reads the password from the
file that `komorebi.krdp.passwordFile` names when it exists. The display device,
the port forwards, the memory and whether to insist on KVM are left to the
environment of the runner, so that one closure and one disk run with a software
virtio-vga or with a virtio-vga-gl that renders on the host GPU. The module is a
separate file that does not import plasma-vm.nix, so that a VM suite can put it
on the session node.
plasma-guests-eval asserts the same of the demo guests.
The Plasma guests were made for an Apple silicon Mac only: the flake fixed the
guest to aarch64-linux and the host of QEMU to the Mac. `mkPlasmaGuest` now
takes the system of the guest and the packages of the machine that runs QEMU,
and the flake has the two QEMU guests for a Linux machine with KVM as well:
plasma-vm-x86_64 and plasma-vm-session-x86_64, and the same pair for aarch64
(plasma-vm-aarch64, plasma-vm-session-aarch64). The three guests of a Mac keep
their names and are built from the same instructions.
An x86_64 machine has a VGA that QEMU adds unless it is told not to, which would
be a second display next to the virtio-gpu that KWin draws on. An x86_64 guest
therefore gets virtio-vga, a virtio-gpu that is also the VGA, and `-vga none`;
an aarch64 guest has no VGA and keeps virtio-gpu-pci.
plasma-guests-eval evaluates every guest and asserts what each is for: the
architecture of the guest, the system of its host, KVM or HVF, and one display
device. docs/dev/utm.md says which guest is for which host and how to build and
run one on a Linux machine; the README and CONTRIBUTING say that there are
guests for both.
The port can only be tried on a Windows machine, through a NixOS virtual machine
in WSL2, which the machines this history is built on do not have. What such a
machine can do for a Plasma guest is not known until something runs there, and
every guess about it is a risk for what comes next. wsl2-probe is that
something: one command, nix run .#wsl2-probe, that answers in about two minutes
what the guest needs to know and prints, for each answer that is not a yes, the
exact change: the .wslconfig lines, the NixOS option, the PowerShell command.
It checks the environment (WSL2, memory, disk, .wslconfig, Nix); KVM (/dev/kvm,
its group, and a tiny guest booted under KVM and under TCG, with the same loop
timed in both and on the machine itself, which must differ by several times);
the display (a QEMU GTK window through WSLg for a few seconds, and whether you
saw it); the GPU (/dev/dxg, the Windows driver libraries, the OpenGL renderer in
four environments, and virtio-vga-gl with gl=on); the Windows side (interop,
mstsc.exe, whether Windows reaches a port that WSL listens on); whether memory,
cores and disk are enough for the real guest; and virtiofs, which the real guest
uses for its /nix/store and every shared directory (/dev/fuse, virtiofsd as the
user with the options of nixpkgs' runner, and a guest that mounts the host's
/nix/store and a writable directory, reads, writes and compares). Each probe
runs apart from the others, so one that fails leaves the rest alone, and the
output ends in a block to paste back, which is also written to
wsl2-probe-report.txt.
The flake wraps the script with QEMU, virtiofsd, Mesa's eglinfo and glxinfo and
socat from nixpkgs, and builds the guest, a kernel from the binary cache, the
two modules of it that virtiofs needs and a static busybox initrd, as
wsl2-probe-guest, so nothing is compiled on the machine. Two checks keep the
script from rotting: wsl2-probe builds the wrapper, which runs ShellCheck over
the script and over the guest's init, and wsl2-probe-dry-run runs --dry-run in
the build sandbox, which has no KVM, no network and no display.
docs/dev/wsl2-probe.md says what each check means and how to read it.
nixpkgs moves from d3b13ad (2026-10-24) to f05535a (2026-10-27) and rust-overlay
from c7e9d51 to 19ecdd0; the other six inputs have no newer revision. KWin,
Plasma and KRDP go from 6.8.1 to 6.8.2, so testedMax in nix/supported-kwin.nix
goes to 6.8.2, with its dated comment. Qt (6.12.0), FreeRDP (3.32.2) and the
glibc of nixpkgs (2.44) keep their versions. The stable Rust toolchain stays at
1.99.1; the nightly rustfmt moves from 2026-10-27 to 2026-10-28.
nixpkgs now has KDE Rounded Corners 0.11.0. nix/kde-rounded-corners.nix still
sets the version and the source, because its patch is written for the 0.11.0
source, so the package does not change: it builds with its patch, and Geometry
Change builds, against KWin 6.8.2. The dated sentences of README.md, DESIGN.md,
PLATFORM.md, COMPARE.md and of the docs of kwin/effects.rs say 2026-10-28 and
the new versions. Measurements taken on 6.8.1 keep their date and version, since
none was repeated on 6.8.2.
The glibc floor does not move: komorebi and komorebic still need 2.39 on aarch64
and on x86_64 (pidfd_getpid and pidfd_spawnp, both weak references), measured as
the build job measures it, before and after patchelf.
The gate with the nix checks passes on an aarch64 box and on x86-1,
nixos-module-eval among them (the KWin version scenarios included). The VM
suites run against the tip of these two commits; the result is in the message of
the next commit.
The VM tests boot a machine, run a scenario and power it off. Trying a change by
hand needs a Plasma session that stays up, and on a Mac, one that renders on its
GPU.
nix/dev/plasma-vm.nix is a guest for QEMU on an Apple silicon Mac, headless or
with a Plasma session that logs in by itself, and nix/dev/plasma-utm.nix is that
session as a disk image for UTM, whose QEMU renders on the Mac's GPU. They are
nixosConfigurations of the flake, and install komorebi with services.komorebi
from the flake's packages. They carry no key, password or configuration of
anyone's: the console logs in by itself, ssh takes the keys a user puts in the
guest, and the RDP password is a file in the guest. plasma-guests-eval evaluates
the three on every system.
nix/dev/krdp.nix runs KRDP in the session, and the slow suite vm-rdp runs the
same unit in the session node: it waits for a password and listens once it has
one, FreeRDP's client is let in with the password and not with another, and the
picture the client gets on an X server of its own is the display. FreeRDP
decodes KRDP's H.264 with OpenH264 and shows nothing, so the guests' client is
built without it and decodes with FFmpeg. Keys over RDP stay unverified, since
no client can script them against KRDP; PLATFORM.md says so and what the suite
checks.
docs/dev/utm.md says how to build and run the guests, and what a builder has to
be.
komorebi relies on the per-output virtual desktops of KWin 6.8, and the
repository follows the tip of nixpkgs-unstable, so a system can have a KWin that
is too old, or one that no VM suite has run against yet.
nix/supported-kwin.nix records both ends: min, the oldest KWin komorebi
supports, and testedMax, the newest one every VM suite has passed against
(6.8.1, with nixpkgs d3b13ad). It is a plain attribute set, so a CI job can read
it with `nix eval --file`. The module asserts that pkgs.kdePackages.kwin is min
or newer, and warns when it is newer than testedMax;
services.komorebi.kwin.untestedIsError makes that an error.
nixos-module-eval gives the system a KWin of a version of its own, so that no
check depends on the KWin of the lock, which moves with the tip, and checks the
assertion, the warning and the option in ten more checks. CONTRIBUTING.md,
PLATFORM.md and vm-tests.md say how testedMax is raised: by a commit, once every
suite has passed against the newer KWin, that says which suites ran.
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.
kglobalaccel keeps the actions of a client that died, and their keys: a daemon
that is killed leaves its keys swallowed and running nothing until they are
unregistered. And kglobalaccel runs inside KWin, so a KWin that restarts forgets
every key komorebi registered. Neither should leave a user without keys.
kwin::hotkeys::release unregisters every action of the component, whatever
registered it, and komorebic hotkeys release runs it, with or without a daemon.
The NixOS module's unit runs it after the daemon stops (ExecStopPost), however
it stops, and a start already takes over what is left. The KWin backend's
NameOwnerChanged watch now also follows org.kde.kglobalaccel: when it has an
owner again, kwin::hotkeys::rebind loads the key bindings into the new one,
trying for 15 seconds.
Loading moves from the daemon's main into kwin::hotkeys::load, which keeps its
settings (Keybindings: file, format, plan mode, engine options), so that reload
can read the file again: the message ReloadHotkeys, komorebic hotkeys reload. A
new engine replaces the running one without unregistering its keys, and takes
them over as a start does, so the keys both files have stay grabbed. The message
HotkeysState answers with the engine's mode, the combos it holds and whether a
chain is pending (null without an engine); komorebic hotkeys state prints it
with the actions kglobalaccel has for the component. komorebic now depends on
komorebi for the two calls to kglobalaccel, and on serde_json for the state.
Tests: the socket messages without key bindings, state and release without a
session bus, reload without a daemon, and a nixos-module-eval check of
ExecStopPost. The VM test vm-restart-survival runs the module's unit in a Plasma
session: a key works, hotkeys state shows it; with the daemon stopped by SIGSTOP
the key runs nothing until hotkeys release gives it back; after SIGKILL the
unit's journal shows the release and the restarted daemon has the key; after the
KWin process is killed, the daemon registers the key with the new KWin; and a
reload of a changed file swaps the key.
vm-keys-engine asks the engine and does not sleep. A key that is not grabbed yet
reaches the focused window, which showed as a binding that does not run, so the
suite presses one once komorebic hotkeys state answers, which it does when the
engine has made the calls of its last event: for a mode, for a chord chain
beginning and ending, and for the keys of the application that takes the focus.
It waits for the old daemon to exit before it starts the next (a daemon started
meanwhile failed to load its KWin script), and activates a window until KWin has
it (KWin lists a window before it can have the focus). The last check reloads
the key bindings with komorebic hotkeys reload while wev has the focus and every
binding is for the terminal, a start with no key to grab.
skhd and whkd can give one key a different action in each application, or none
(skhd's ~, whkd's Ignore), and skhd has a blacklist of applications in which no
key is taken. The engine decides from the focused application whether such a key
is active: inactive, it reaches the application, which is how a key passes
through. What it needs is to be told which application has the focus.
The bridge reports the desktop entry of every window with its class, and the
table now keeps it. Table::focused_application returns the executable, the app
id (or X11 class) and the desktop entry of the window KWin activated last, a
dialog included, or nothing once that window is gone. The KWin backend hands it
to kwin::hotkeys::focus after every event of the bridge; only a change reaches
the engine's thread, and an engine that starts begins with the focus as it was
last seen. The engine matches the names of the file against the three, ignoring
case.
The names in an skhdrc or a whkdrc are those of macOS and Windows applications,
so the daemon takes --app-alias NAME=ALIAS[,ALIAS]..., more than once, for the
engine's app_aliases.
Unit tests cover the focus of the table and the calls of a scoped key as the
focus moves, an alias included. The VM test vm-keys-engine grows a section with
wev and foot open and --app-alias terminal=foot: in wev, Alt+G (for the terminal
only) and Alt+N (which wev ignores) reach wev and run nothing; in foot both run
their bindings; back in wev, Alt+G reaches wev again.
An sxhkd chain (alt + w ; h) is realized by the engine: after the prefix only
the keys that can come next and Escape are grabbed, because KWin 6.8's own key
sequences never fire. What ends a chain that nobody finishes is the chord
timeout, and the engine has no clock: it is told the time with on_tick. Rather
than ticking on a timer forever, the engine now says when its pending chain
times out (Engine::deadline, in komorebi-hotkeys) and the transport sleeps until
then, calls on_tick, and grabs the keys of the mode again. With no chain pending
it does not wake up at all.
The daemon takes --chord-timeout in milliseconds, 3000 by default, the engine's
default and the module's chordTimeout to come.
A unit test follows the calls of a chain from its prefix to its deadline. The VM
test vm-keys-engine grows a section with an sxhkdrc passed as --keybindings and
a timeout of 1.5 s: Alt+W, H runs the binding and H does not reach wev; Alt+W,
Escape lets the next H reach wev; Alt+W and two seconds later L reaches wev and
runs nothing.
skhd's modes, and sxhkd's chains that stay open, are sets of keys that are
active together; a static shortcut cannot be in one. The engine already computes
the keys a mode wants. What the daemon adds is that a mode switch reaches
kglobalaccel as it should: the keys of the mode left are let go with
setInactive, so that they reach the focused window again, and those of the mode
entered are grabbed, bare keys included, before the next key arrives. It logs
the mode after each change, which is the one way to see from outside which mode
the engine is in.
A unit test follows the calls of entering a mode and leaving it with Escape. The
VM test vm-keys-engine grows a section with wev focused: in the default mode a
bare H reaches wev; Alt+R enters the mode resize and runs its command, after
which H runs its binding and does not reach wev; Escape goes back, and H reaches
wev again. That turns "a key the engine does not want reaches the application"
from a convention into a proved rule.
A static shortcut can only be one combo, pressed, the same in every application.
Modes, chord chains, release bindings and per-application bindings need komorebi
to hold the keys and decide what each press does: the engine of
komorebi-hotkeys, a state machine with no I/O. This commit runs it against
KWin's global shortcut daemon, which KWin 6.8 runs inside itself on the session
bus.
kwin::hotkeys owns the component komorebi in kglobalaccel, with one action per
combo, named after the combo (Alt+H). An activation of the engine is
setShortcutKeys(id, [[combo]], 6), with a doRegister the first time; a
deactivation is setInactive, after which the key reaches the focused window
again. The calls of one event are sent without waiting for each other's answers,
which Phase 0 measured at 60 calls in 2.4 ms. globalShortcutPressed and
globalShortcutReleased of /component/komorebi feed the engine;
globalShortcutRepeated is ignored, so a held key runs its binding once. A
komorebic command runs the komorebic next to the daemon with its words when they
need no shell, anything else runs through sh -c. The calls are computed by
Registry, which is pure and tested; the D-Bus part is proved by the VM test.
The engine hears the presses at the path /component/komorebi and does not ask
kglobalaccel for the object with getComponent. kglobalaccel makes the object
when the component gets its first action, so a start with no key to grab (every
binding is for an application other than the one with the focus) has none to ask
for: getComponent fails with NoSuchComponent, and an engine that asked would
never start. A signal is matched by the path it comes from, so the presses are
heard as soon as there is an object. PLATFORM.md says so.
kglobalaccel keeps the actions and the grabs of a client that was killed, so a
start is an idempotent reconcile: the actions of the component that the keymap
names are taken over and released unless the default mode wants them, the others
are unregistered. A stop releases and unregisters everything, from
KWinBackend::shutdown, which SIGINT, SIGTERM and the Stop message all go
through.
The daemon takes --keybindings FILE, --keybindings-format skhd|whkd|sxhkd (by
default from the file's name) and --keybindings-mode (the mode komorebic hotkeys
compile wrote the static shortcuts in, so that the daemon leaves those to KDE);
without --keybindings it reads the first of skhdrc, whkdrc and sxhkdrc in the
config directory (HOME_DIR, KOMOREBI_CONFIG_HOME). It logs one line about the
file and the diagnostics at debug level. An engine that cannot start is logged
and the window manager runs without keys; the fake backend runs none.
The VM test vm-keys-engine starts the daemon in a Plasma session with an skhdrc
in the config directory, presses its keys (a command, one through a shell,
komorebic retile reaching the daemon), kills the daemon and sees its keys stay
registered, starts it with another file and sees the old keys unregistered and
the new ones work, and stops it with komorebic stop, after which no key is
registered and none runs. The library gains spawn_komorebi,
kill_spawned_komorebi and shortcut_actions, and Checks.finish names the checks
that failed, since nix build shows only the last lines of a failed run. The
suite's node turns the module's unit off: the test runs daemons of its own.
komorebi users keep their bindings to komorebic in a file of skhd, whkd or
sxhkd. On Plasma under Wayland no client sees the keys of another, and the
program that runs a command on a key is KDE's global shortcut daemon, which runs
inside KWin. A binding that is one combo, pressed, the same in every
application, in a file without modes, can be a static shortcut: a .desktop file
that KWin reads by itself, that shows in System Settings and that works with no
komorebi process at all.
komorebic hotkeys compile reads a file of any of the three formats, plans it
with komorebi-hotkeys in the mode it is given (auto, engine or static; the
default is the crate's), prints the diagnostics of reading and planning, and
writes the static shortcuts to $XDG_DATA_HOME/kglobalaccel or --output,
replacing the files it wrote before and no other. --strict refuses a file with a
warning or an error before writing anything, --dry-run says what a write would
change, and --reload hands each new file to the running KWin. komorebic
export-kde-shortcuts keeps the spike's interface for an skhdrc, in the static
mode. Both are thin: the reading, the plan and the files are the crate's. The
bindings that need the engine are counted; the daemon does not run them yet.
docgen gives a subcommand of a subcommand a page of its own
(hotkeys-compile.md). KOMOREBI_CONFIG_HOME, or ~/.config/komorebi, is where
komorebic looks for a file it is not given.
komorebic check gains a section for the key bindings, between the configuration
and the desktop: the first key binding file of the config home, how many
bindings it has and where they go, the lines that cannot be read (a warning, and
the first five) and the bindings not realized as their own daemon would (a
note), and whether the generated files in the shortcut directory are the ones
hotkeys compile would write now (a warning with how many to add, to change and
to remove). --configuration-only keeps it, as it looks at files.
The VM test vm-keys-static boots a Plasma session with shortcut files that
hotkeys compile wrote into the system profile at build time, presses their keys
through QEMU's keyboard, and sees each command run, a % in one of them included;
then it writes a binding in the middle of the session with export-kde-shortcuts
--reload and presses it. The library gains Keys, which sends a combo as KDE
writes it through QEMU's sendkey.
komorebi fails quietly when the desktop is not what it was made for: over ssh
there is no session bus, a daemon whose script is not in KWin tiles nothing
while it runs, and komorebi needs KWin 6. `komorebic check` now looks at the
desktop after the configuration, and `--configuration-only` leaves that out for
a machine that is not the one komorebi will run on.
It looks at the session (KDE, Wayland), the session bus, KWin on it and KWin's
version, the daemon and its script (the daemon is running when its socket takes
a connection, the script is in KWin when KWin says it has loaded it), and what
starts komorebi at login. A bus that cannot be connected to or does not answer,
and no KWin on it, are errors, and the looking stops there because nothing after
them can be answered. Every call has two seconds to answer, so a bus that never
does cannot hold the check.
The test of the missing session bus used to remove the address and the runtime
directory from the environment and so depended on it: a machine with a user bus
at /run/user/UID/bus answered it. It now gives an address with no socket behind
it. A bus that accepts and never answers, the autostart finding and
--configuration-only have tests too, and the VM suite vm-check runs the command
against a real KWin with the daemon running, with its script gone, with no
daemon and with no KWin on the bus.
It also looks at the two effects KWin draws and animates with, and at the Plasma
shell. Only komorebi's builds of them do everything komorebi asks (a color for
each kind of window, every animation style), so the check tells a build by what
it contains: the interface of the border effect in its plugin file or its object
on the bus, a Curve setting in the animation effect's script. It looks for them
where KWin looks, from KWin's own environment, and a stock effect is a warning
only when the configuration asks for what it cannot do (borders, an animation
style other than the stock curve), and so is a copy in the user's own data
directory that hides komorebi's. The Plasma shell is looked for when the file
has wallpapers. vm-check runs all of it against KWin.
A window that opens goes after the focused container. A workspace can now say
another place for its windows: the primary or the secondary tile, before or
after the focused container, the end of the list, or a place by number, counting
from 1. The place is for every window, or for the windows that match a rule on
their program, app id, title or path; the rules are the conditions the ignore
and manage rules are made of, and the first that matches in key order decides. A
place that does not exist, such as the secondary tile of a workspace with one
container, is the default place.
A place is read from a name, a number or text that is a number. The
documentation of the setting shows a number and a map's keys can only be text,
and komorebi for Windows (83c4e11d) reads only text, so the form its own page
shows is refused there.
A place that was reserved with preselect-direction is used before the rules are
asked, and a locked container keeps its index. A workspace whose
window_container_behaviour is Append puts a window in the focused container, and
the rules are not used.
A workspace takes the rules from the key initial_window_placement_rules of its
entry in komorebi.json. The key is in schema.json and so in the typed config
option of the module, and the page docs/initial-window-placement-rules.md says
how to write it. vm-placement opens windows in a headless KWin and checks where
they go, by program, app id and title.
The schema that schemars derives for a place is an object with a Placement or an
Index key, which is not what is read or written, so a check against it refuses a
file that the daemon reads. The schema of PlacementTarget is written by hand
instead: a name, a number, or text that is a number. A file with a place of each
form is checked against schema.json, and the module's config option takes them.
A fullscreen window covers its monitor on purpose. Moving it would take it out
of fullscreen, or be ignored, so Window::set_position does nothing for a
fullscreen window, and every move the window manager makes goes through it.
The bridge reports KWin's fullScreenChanged as a fullscreen event, and the table
keeps what it says, which is what the window manager asks. The window stays in
its container, and the others are tiled as if it were not fullscreen. When it
comes back from fullscreen, KWin gives it the frame it had before, which may not
be its tile any more, so the workspace is tiled again.
Section E of the features suite checks it in a real Plasma session: a fullscreen
window covers the monitor, a window that opens does not take it out of
fullscreen, and it is in a tile that overlaps no other when it comes back.
KWin maximizes a window for the user as well as for komorebi: the title bar, a
double click and a shortcut do it, and nobody asks the window manager. A window
that stayed a tile would be asked to move at the next retile, so komorebi has to
know.
The bridge reports KWin's maximizedChanged as a maximized event, true only when
the window is maximized both ways. The table turns it into a MaximizeChange, and
adopt_maximize_change takes the window out of the layout as toggle-maximize
does, or, when the user restores it, puts it back in a container of its own at
the index it came from. A window that is already maximized when komorebi starts,
or that opens maximized, is the workspace's maximized window from the start.
komorebi's own maximize is reported too and finds the workspace as it left it,
so it changes nothing.
While a window is maximized, what is asked of the layout does nothing, by the
same rule as for toggle-maximize.
A maximized window of a monitor that is unplugged goes to the monitor that is
left and stays maximized: evacuate_monitor makes it the maximized window of the
workspace it goes to, and the maximized window that workspace had goes back to
its tile. Until now it came back as a tile.
vm-user-maximize maximizes windows with kdotool in a headless KWin, and checks
the daemon's state, the frames, that the layout commands do nothing, and that
toggle-maximize and the user's restore both put the window back in its tile.
While the screen is locked or the machine is asleep, KWin sends its clients no
frame callbacks, so nothing komorebi asked for in that time is done: a window
that something else moved stays where it was moved, and the monitors can come
back in another order or at another size. Nothing told komorebi it had happened,
and it kept the layout it had until the next event.
kwin::power now watches for the two ends of it: logind's PrepareForSleep on the
system bus, which only logind may send, and the lock screen's ActiveChanged on
the session bus. When the machine wakes (2.5 seconds after it, while the outputs
are found one after another) or the screen is unlocked (0.6 seconds after it,
once the lock screen has gone), the monitor reconciliator gets a Wake and calls
wake_up: it reconciles the monitors as for an unplug, reads their sizes, follows
the windows to the monitors they are on and tiles every monitor, unless the
window manager is paused. Going to sleep and locking do nothing, and a machine
with no system bus or a session with no lock screen runs without them. The lock
screen is a window of KWin's that the bridge already does not report as an
application window, so it has no tile.
The bridge also compares KWin's active window with the one it last announced
once a second, because the window that is active again after an unlock is not
always announced. vm-lock-sleep locks and unlocks a real Plasma session and
checks that the windows come back to their tiles; a real suspend cannot be
tested in the QEMU guest, only the signal wiring, which tests/power.rs covers on
private buses.
vm-lock-sleep waits for the panel's room before it opens the windows, so that
they are tiled once, and compares the window that was moved with the tile the
daemon has for it when it looks, give or take a cell of the terminal's font, and
not with the frames read earlier: the room can come while the screen is locked,
and the tiles read before are then not the ones. The wait is not a check,
because a session on a machine as slow as TCG may never take the room.
A window can be moved to another output by something other than komorebi: a KWin
shortcut that sends it to the next screen, the window menu, an application.
komorebi had it in a container of the old monitor, whose tile is on a screen the
window is not on, so it sat untiled where it landed.
The bridge now reports a window's output changing, with the frame the window has
by then, since the signal and the frame arrive in no fixed order, and the table
makes it an OutputChange event. The window manager handles it with
WindowManager::follow_windows_to_their_monitors: every container whose focused
window, and every floating window, is on another monitor than the one it has it
on moves whole to the workspace of the same number on the monitor that holds the
middle of its frame, and the monitors that changed are tiled. Every window is
looked at, not only the one in the event, and a move komorebi made itself is in
its state already and finds nothing to do.
Nothing is followed while the user drags a window: the end of the drag decides
where that window goes, so the method returns at once while a move or a resize
by the user is going on.
KWin also moves windows for a moment after outputs come and go, so the monitor
reconciliator looks again 1.5 seconds after each notification, where it used to
trust what it found at once. vm-hotplug sends windows over with kdotool as well
as with komorebic.
KWin takes the windows of an output that goes to the outputs that are left and
puts them where it likes, so komorebi's tiles for them were on a screen that was
gone and the windows sat untiled where they landed. The monitor reconciliator
now deals with a change in the set of monitors: the table announces it as a
display connection change instead of a resize, and reconcile_display_change
reads the monitors again, keeps each one that went (workspaces, layouts,
paddings, offsets) in a cache, has the window manager move what was on it to the
monitors that are left, and removes it.
The move is WindowManager::evacuate_monitor, in the new reconcile module: each
container and floating window goes to the workspace of the same number on the
monitor that holds the middle of its window, or on the first monitor that is
left when it is on none, and the workspaces that changed are tiled. A stack goes
as one container, and a monocle and a maximized window come as ordinary
containers. A monitor that is plugged in takes what was cached under its serial
number id, less the windows that closed or that the window manager has elsewhere
by now, so it comes back with its settings and none of the windows it had. A
monitor komorebi never saw gets workspaces of its own, and when the compositor
reports no output at all nothing is done.
The workspace rules of a monitor that goes are dropped, and those of the
workspaces of one that comes back apply again. komorebi.json fills the cache as
well: a monitor that has the entry its display index preference names is kept
with it, and so is the entry of each preference whose monitor is not connected,
which that monitor takes when it is plugged in.
vm-hotplug now sends two windows to the other monitor with komorebic, disables
that output, enables it again and sends a window over once more.
When an output gets another resolution or scale, or a panel starts, grows or
hides, the work area the layout fills is not the one komorebi tiled in, and
nothing moved the windows until something else tiled them again.
The bridge now sends the outputs, with their geometry and the work area of the
desktop each shows, when KWin says they changed, when a dock window opens,
closes or moves, and once a second, because KWin has no signal for the room a
panel leaves. The table turns a monitor whose size or work area changed into a
monitor notification. It is not a window event, since it is about no window: it
goes to the monitor reconciliator, a thread that takes the window manager's lock
as the threads of events and messages do, reads the size and work area of every
monitor again and tiles the workspace in front of the focused monitor. Another
monitor's windows keep their tiles until a retile. Every subscriber is notified
of it, whether or not the state changed.
vm-hotplug starts with the scale of one of two outputs changing under a running
daemon. The VM library gets kde.outputs, which lists, disables, enables and
scales outputs, for the commits that unplug and plug them.
While the user drags an edge of a tiled window, the tiles next to it follow, and
not only once it is let go.
KWin reports every step of a resize with the frame the pointer asks for. The
bridge passes one on every 16 ms at most, the newest, with a single-shot timer
for the last one of a burst, and the window manager keeps at most one step
waiting, since each says where the edge is now. ResizeStart keeps the layout as
it is when the user takes hold (LiveResize), and every step and the end are
worked out from it: a drag ends the same with its steps as without them, and one
that is taken back puts the neighbors back. The dragged window is the user's
until they let go, so Window::set_position leaves the windows being resized
alone, whatever tiles the workspace.
vm-live-resize holds the edge part way and all the way and reads the neighbors
while the button is down. With the neighbors following, KWin's window snapping
pulled a dragged edge 9 pixels past the pointer in vm-drag-resize, since the gap
between two tiles is inside its default zone, so both drag suites turn snapping
off; PLATFORM.md and drag-resize.md say so. Like vm-drag-resize, it drags
against the daemon the module starts with the session, and reads the drags that
daemon has handled from the unit's journal.
vm-live-resize waits for the panel's room (Kde.wait_for_panel_room) before it
opens the windows. The daemon learned of the room while the pointer was down in
a first case that had begun without it, and the retile that came with it moved
the neighbor, not the pointer.
Dragging an edge or a corner of a tiled window resizes its tile when the user
lets go: each edge of the tile moves by what the pointer moved it, the neighbors
give up or take the room, and the window is put on its tile.
A drag is measured from the frame the window had when the user took hold of it,
edge by edge, and resizes the container of the window that was dragged, through
resize_window and so within its bound (no tile below a tenth of the work area).
KWin reports the window's frame all through a drag, so the table keeps the frame
of the start for the window manager (Backend::drag_origin). At the end the frame
can still be short of the pointer, because KWin changes it once the client has
drawn at the new size; the bridge keeps the frame the last step of the drag
asked for and sends it as `requested`, and the end of a resize is that frame.
The window of a stack has the tile of the stack; a floating window and the
window of a monocle have none, and are left as the user made them.
The end of a resize is read apart from the window's frame, and that deviates
from the spike. The spike stores the frame the last step asked for as the
window's own frame, where the next frame event replaces it. KWin sends one a
millisecond after the end, with what the client has drawn so far (660 pixels of
the 672 asked for), and a window manager that is busy with an earlier event
reads that frame when it handles the end: a tile moved by 60 pixels for a drag
of 72. Here the table keeps the end apart (Table::drag_end, and
Backend::drag_end for the window manager, None by default), ResizeEnd reads it
as ResizeStart reads drag_origin, and the window's frame stays the one KWin
reports. A resize that sent no step ends at the frame. The order that failed is
a test of the KWin backend with the real table and window manager, in which the
tile took 140 of the 200 pixels without this.
komorebi-layouts at the pinned revision has the fix of LGUG2Z/komorebi#1765, so
nothing is vendored, and docs/drag-resize.md says what a drag does and why each
rule is there. vm-drag-resize drags edges and corners of three tiles with the
pointer that the session node has (komorebi_vm.Pointer), whose moves are batched
in the guest. The suite drags against the daemon the module starts with the
session, and reads the drags that daemon has handled from the unit's journal.
vm-drag-resize waits, for 30 seconds at most, for the daemon to have the room
KWin takes for the panel before it opens the windows (Kde.wait_for_panel_room).
The panel moved every tile in the middle of a case that began before the daemon
learned of it, which showed as an edge that was not dragged. It is a wait and
not a check, since a session that is too slow may never take the room.
Plasma keeps one wallpaper for each screen, not for each virtual desktop, so a
workspace that wants a picture of its own has nowhere to keep it in the shell.
komorebi sets the wallpaper of a screen when a workspace comes into view: the
workspace's own, else its monitor's. It does so however the workspace came into
view (a komorebic command, a pager, an application raising a window) and for the
workspace in front when it starts. A monitor and a workspace with no wallpaper
are left alone.
The Plasma shell sets it over D-Bus, with the call plasma-apply-wallpaperimage
makes, but for one screen. Backend::set_wallpaper asks for it every time a
workspace comes into view, and the KWin backend asks the shell what the screen
shows first, so a picture the user changed by hand is put back and one that is
already right is not touched. The request runs in the background, so switching
workspaces never waits for the shell, and goes on trying for about half a minute
when the shell is not up yet.
A wallpaper also gives the borders the colors of the palette made from its
picture, unless it says generate_theme is false, and theme_options choose the
variant and the color each border takes. The colors change before the workspace
is shown, so its borders are right at once.
komorebi.json takes the wallpaper of a monitor and the wallpaper of a workspace,
and a file that is read again shows the wallpaper of the workspace each monitor
has in front at once. vm-wallpaper runs against the real shell: set at start and
by workspace, a switch komorebi did not make, the colors of the borders, a
wallpaper changed by hand, the palette cache, and komorebi that starts before
the shell.
A theme gives the borders their colors, in place of choosing the color of each
kind of window: a Catppuccin theme, a Base16 theme or a palette of one's own,
with the color it gives each of the six kinds of border and its default for the
ones it does not name. The Theme message puts the six colors where the border
manager keeps them and asks for the look again. The palette of a picture is made
by the same generator as komorebi for Windows, which takes seconds for a large
picture, so each one is kept in the cache directory, in a file named for the
picture, a hash of its path, size and time of last change, and the variant: the
palette of a picture painted over, or of one of the same name in another folder,
is made again and not mistaken.
The themes come from komorebi-themes at the revision komorebi-layouts is at. It
pulls egui for its types, which the license list, the sources and the advisories
of deny.toml now have to allow, and the colors the border manager keeps are the
themes' own again.
A subscriber that asks for the changes of the state only is sent a Theme message
all the same: the colors of the borders are not part of the state, so a theme
never changes it, and the subscriber would not hear of the colors at all.
komorebi.json takes border_colours, a color for each kind of window as red,
green and blue or as a hex color, and a theme, which wins over them.
LGUG2Z