mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-11-15 13:22:19 +01:00
00aec79ee44767aa573f5eda67c8b8eedf394223
20
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 LGUG2Z
|
c59f5dddd0 |
build(nix): scale of 1.5 on every Linux host, and what the suites take on WSL 2
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. |
||
|
LGUG2Z
|
1ee2405e44 |
docs(repo): trying komorebi in a virtual machine
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. |
||
|
LGUG2Z
|
e37f275b9b |
feat(nix): run-kde, the command
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. |
||
|
LGUG2Z
|
041dd35224 |
build(nix): the demo guest
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. |
||
|
LGUG2Z
|
146e794b7b |
build(nix): guests for a Linux host
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. |
||
|
LGUG2Z
|
9b60a0020d |
chore(scripts): probe a WSL2 NixOS VM for KVM, WSLg and RDP
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. |
||
|
LGUG2Z
|
8b9cde08d0 |
build(nix): Plasma guests to develop against
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. |
||
|
LGUG2Z
|
9cb26daf38 |
build(nix): keybindings in the module
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.
|
||
|
LGUG2Z
|
0520068b48 |
feat(hotkeys): the binding IR, key names to Qt codes and a fixture corpus
komorebi users keep their bindings to komorebic in the file of a hotkey daemon: an skhdrc on macOS, a whkdrc on Windows, an sxhkdrc on X11. On KDE Plasma the program that runs a command on a key is KDE's global shortcut daemon, so the bindings have to be read and turned into shortcuts. This adds `komorebi-hotkeys`, a crate of its own that does not depend on the daemon, with the model all three formats are read into: a `Keymap` of modes of bindings, each a chord, an edge and a body (a command, a mode switch, or one action per application), and `Diagnostic`s with spans. A key is a Qt key code with the modifier flags or'ed in, which is what kglobalacceld stores, so the same key is the same value whatever file named it. `qt::key_to_qt` knows the three vocabularies: skhd's literals and macOS keycodes, whkd's virtual key names and sxhkd's X keysyms, including the XF86 media keys. `Combo` applies the shifted symbol rule measured on KWin 6.8.1 (Alt+Shift+1 arrives as Alt+!), and its fields are private so that no combo skips it; a `compile_fail` example proves it. Positions are read as on a US layout. The fixture corpus writes each case in every format that can express it; the parsers are written against it. The flake's source filter keeps the fixtures, so that the nix checks can read them. |
||
|
LGUG2Z
|
0210ec285a |
feat(kwin): sleep, wake and lock
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. |
||
|
LGUG2Z
|
2b116ea2a3 |
feat(kwin): wallpapers for monitors and workspaces
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. |
||
|
LGUG2Z
|
4fa8108110 |
feat(kwin): animation through the Geometry Change effect
Windows that jump to their new places are hard to follow. komorebi animates nothing itself: KWin's Geometry Change effect animates a window that a script moves, and komorebi tells it how long that takes. The look the window manager asks the backend for now has an animation, a duration that the settings give for every kind of animation or, when one is set for the movement of windows, for that one. The KWin backend writes the effect's settings into the user's kwinrc (a duration, and no cross-fading, since a window going to its place changes where it is and not what it shows), loads the effect when animation is on, and unloads it and puts the settings back when it is off or komorebi exits. komorebic gets animation, animation-duration and animation-fps. The module installs the effect (effects.animation), and the session node sets the variable that makes KWin load effects that animate under software rendering. vm-look reads the screen a moment after a flip of the layout, with a 30 s animation and without one. The commands that change a stack turn the animation off while they run, as komorebi does elsewhere, and komorebi.json takes an animation key (enabled, duration and fps, each for every kind of animation or for one). |
||
|
LGUG2Z
|
2c35e4bb6f |
feat(kwin): borders drawn by the compositor
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. |
||
|
LGUG2Z
|
3a3a0f8f24 |
feat(wm): JSON schemas, and the module's typed options
komorebi.json is described as a JSON Schema, made from the Rust types that read it: komorebic prints the schema of komorebi.json, of an applications.json, of a notification and of a message, and the daemon answers the same four questions on its socket. schema.json and schema.asc.json are committed (just jsonschema). The module's config option is typed from the schema: schemars-nixgen makes nix/komorebi-options.nix from schema.json (just nixgen), so a layout komorebi does not have, or a value of the wrong kind, does not evaluate. The module writes config as a komorebi.json and gives it to the daemon with --config. configFile and the file the module writes are checked against the schema when the system is built. applicationSpecificConfiguration takes files from GitHub, and there are none by default, since no community file for Plasma is known. Two checks keep the generated files honest without the tools that make them. schema-fresh compares the schemas with what komorebic prints, and the hash on the first line of the options with the schema. nix-options-validation evaluates the options against the example configuration, written in Nix and in JSON. nixos-module-eval also evaluates the module with the sources turned off: with applicationSpecificConfiguration.enable = false the sources are left out of the config that is written, and with no config either there is nothing to write and the unit passes no --config. ARCHITECTURE has the guarantee row that names the two checks. |
||
|
LGUG2Z
|
5eaa613f50 |
feat(wm): configuration in komorebi.json
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
|
a86e2bdc63 |
build(nix): a NixOS module for komorebi
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. |
||
|
LGUG2Z
|
6f657e53e3 |
feat(cli): komorebic
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
|
15ec3c1274 |
feat(kwin): read the desktop through a script in KWin
KWin has no protocol that lets another process read or set the geometry of a window, but its scripting API has both, and a signal for every change the window manager follows. So the KWin backend is in two parts: bridge.js, a script the daemon loads into KWin, which reports what KWin sees and holds no window manager logic, and a D-Bus service in the daemon, org.komorebi.Bridge, which the script calls with every event as a JSON string. Every decision about what an event means is made by the table in kwin::state, which is pure and is unit-tested with the JSON the script sends: which windows may be managed, the ids komorebi gives KWin's windows, and the Show, Destroy, FocusChange, Minimize and Restore events of the window manager. Events reach the window manager in the order KWin raised them: the Event interface handles its calls inline (zbus reordered them otherwise), and one channel and one thread, window_manager_event_listener and listen_for_events, carry them on. Commands go to the script as the answer to a Poll call that the script always has open and the daemon holds until it has something to send: in the spikes this was as fast as any other channel, and it makes one call every 10 seconds when nothing happens. Here the only command is the cursor query. Every command of the Backend trait is refused with "the KWin backend only reads the desktop", so the daemon follows KWin and moves nothing. The bridge is JavaScript that KWin runs as it is, and it gets types and tests without a JavaScript build chain. tsc checks it as strict TypeScript through JSDoc types of every message, against kwin-api.d.ts, a declaration of the part of KWin's scripting API it uses, in which every property is read-only and callDBus takes one string. bridge.test.js runs it under node --test against a fake KWin in a node:vm context. The messages of a session are JSON fixtures that both sides' tests read: the bridge's tests check that it sends those events, and the table's and the backend's tests read the same events and commands, so a message cannot change on one side alone. just check-js and the flake's komorebi-bridge-js check run both, with nodejs and typescript from nixpkgs; there is no package.json. The daemon now connects to KWin by default, and --fake-backend is hidden. The VM suite vm-kwin-events starts it against a headless KWin and checks, from its debug log, that the script loads and reports what was open, that KWin's signals arrive as events and in order, and that stopping the daemon unloads the script. docs/dev/PLATFORM.md starts with what komorebi needs from Plasma. zbus 5's zvariant, zbus_names and zvariant_derive are flagged unmaintained, since their code moved into zbus 6; deny.toml ignores the three advisories. |
||
|
LGUG2Z
|
3c51b9b4bf |
build(nix): a NixOS test framework for headless KWin
The unit tests run against a fake desktop and cannot say whether KWin does what the daemon asks. This adds the other half: NixOS machines with Plasma in them, a real KWin, and a Python library to drive it. Every directory under `nix/tests/vm/suites` is a test. The generator lists the directory, so a new suite appears as `checks.<system>.vm-NAME` on Linux and as `legacyPackages.<system>.vm.NAME` everywhere, with no edit to the flake. A suite names its tier and its node and has a `test.py`; `legacyPackages.<system>.vmTiers` lists the names of each tier as JSON for the CI matrix, `vmGuests` the guests to build on a Linux builder, and `vmTcg` the same suites for a machine with no KVM. `scale` multiplies every wait: 1 for KVM, 1.5 for HVF, 8 for TCG. The headless node runs `kwin_wayland --virtual` as user units of a lingering user, one pair of units per session (`session-bus@NAME`, `kwin-virtual@NAME`), so a test can run several sessions with their own bus and socket. A virtual KWin has no output to draw on, so anything that needs pixels or a pointer needs the session node. The library, `komorebi_vm`, has `Checks` (counted checks that fail once, at the end) and `Kde` (start a session, run clients and tools inside it, read windows through kdotool, poll with `wait_for`). It depends on a small `Machine` protocol rather than on the test driver. The `vm-lib` check runs its unit tests against a fake machine, with ruff and ty. The driver type checks each `test.py` with ty, which is how a protocol that did not match `QemuMachine.execute` was caught. `vm-kwin` starts a KWin with two outputs, spawns a foot window, reads it back, starts a second session and checks that it cannot see the first. On a Mac the guest is built on a Linux builder and the driver run directly, because the macOS nix sandbox cannot give QEMU the hypervisor: `scripts/vm-mac`, `just vm NAME`. docs/dev/vm-tests.md covers this, adding a test, and the builder. |
||
|
LGUG2Z
|
9524b777b3 |
build(nix): build and check on Linux and macOS
The flake builds the workspace with crane and checks it the way `just check` does, so that CI and a laptop run the same things: `komorebi-workspace-fmt` (nightly rustfmt, since rustfmt.toml uses unstable options), `-clippy` with warnings denied, `-doc` with rustdoc warnings denied, `-toml-fmt`, `-deny` and `-nextest`. Treefmt and a pre-commit hook format Rust, Nix, TOML and the justfile. `nix develop` gives a toolchain with the nightly rustfmt, cargo-deny, nextest and udeps. Linux is where komorebi runs, so only Linux gets packages and the overlay. An Apple silicon Mac gets the dev shell, the formatter and the checks; the tests there run against the fake desktop that arrives with the backend trait. x86_64-darwin is left out because nixpkgs 26.11 dropped it, and the flake follows the tip of nixpkgs-unstable. The commit hash is a constant (`nix-check`) for the dependencies and for every check, and the real one only goes into the final build. The version crate reads it with `env!`, so putting it in the shared arguments would rebuild the dependencies and rerun every check for each commit. The README and CONTRIBUTING.md describe `nix develop` and `nix flake check`. |