Excludes /komorebi-for-kde and /komorebi-for-mac from the Windows crane source filter so their edits do not invalidate Windows builds and their Cargo.lock files are not swept in. Verified: the Windows clippy check still passes.
komorebi/src/pan.rs and komorebic/src/pan.rs include_str! the .txt files in komorebic/fixtures/, which the crane source filter dropped, so the nix build failed. Adds the fixtures to the filter. Verified: nix komorebi-workspace-clippy passes.
e2e/guest/testwin/src/main.rs had an unsafe block inside an unsafe block, which clippy -D warnings rejects (unused_unsafe). Removes the inner one without changing behaviour. Verified: Windows clippy passes.
Merges the macOS old repo's history, with its original commit hashes, under komorebi-for-mac/. The subtree is byte-identical to the old tip 9a58e511 (306/306 renames in the move commit). Verified: tree equality, git blame, git log --follow, cargo metadata, and that no macOS workflow sits outside komorebi-for-mac/.
Merges the KDE old repo's history, with its original commit hashes, under komorebi-for-kde/. The subtree is byte-identical to the old tip 7d19fd40 (654/654 renames in the move commit). Verified: tree equality, git blame, git log --follow, cargo metadata, and that no KDE workflow sits outside komorebi-for-kde/.
toggle-monocle leaves IGNORED: it turns the monocle of the tiles that
are left on and off while the window stays maximized, as probed on
komorebi for Windows.
komorebi for Windows does not ignore it while a window is maximized: the
monocle of the tiles that are left comes on and goes off, and the window
stays maximized. Match it, and drop toggle-monocle from the commands
that are about the tiles.
The tests are cross-compiled for Windows, so they run there: cargo_tests.py
uploads each test executable, lists its tests and runs every one in a
process of its own, as nextest does. The nix check never ran them
(doCheck is false).
komorebic's build script (reqwest) runs on the build host and needs
pkg-config and OpenSSL, as in the nix build, so cargo test --workspace works
from nix develop.
On a komorebi with 3fa3d429 the step passes its tracking checks; what is
left is that toggle-float and stack left/right are not ignored while a
window is maximized. The marker says so for such a build.
komorebi-testwin-e2e is the e2e build's test window, so a change to it
rebuilds the crate and not its dependencies (86 s instead of minutes);
build-ref.sh uses it.
The pixel checks of the shared scenarios (the ring of a border by hue) take
the window's own color to be neutral. The default was (48, 80, 128), which
is cool by their measure, so a warm ring beside it read as mixed.
maximizing.user is a known difference only on a komorebi without 3fa3d429
(track a window the user maximizes or restores); on a build that has it
the step runs as any other.
put_file writes bytes to a path in the guest (a folder that has a space in
its name is made), wallpaper and set_wallpaper read and set the wallpaper
of a display through IDesktopWallpaper, with the COM calls in C# compiled by
Add-Type (wallpaper.ps1).
The left, right and bottom borders of a window reach outside its visible
frame (the invisible DWM border), so the press is 4 px outside; the top has
none and its border is inside the window, so the press is in its first
rows. Outside the top the press hit the desktop and no drag started.
maximizing.user (a user's maximize is not the maximized window) and
hotplug.user_move (only a drag relocates a window to another monitor).
Their failing checks are known failures with the reason; a step that has
no failing check says the marker can go.
crash() killed the daemon but not the command that launched it, which wrote
its exit code into the output file after the next launch had started, so
that launch looked as if it had ended and was started again.
QEMU has died with SIGABRT while a second display was plugged in (a
hotplug repeat and monitors.at_cursor), which is not a result about kfw.
Its stderr is kept, a dead guest is named as such, and the scenario is
run once more on a fresh guest.
--rename-to T --after S gives the window another title S seconds after it
opens, as a program that sets its title late does. The message WM_APP + 2
takes it fullscreen, borderless over its monitor, and back.
monitors, layout_flip, title_rule, handover, queries, display_change and
fullscreen, with the extra functions their files have after run
(hotplug.user_move, resize.edge_cases, maximizing.user,
lifecycle_hidden.crash, monocle.focus_behaviour, monitors.at_cursor).
spawn takes rename_to and after (the test window renames itself),
temp_path, crash (kills the daemon), fullscreen and user_maximize (the
user's own, by messages the window understands), with tests: a window
that is not there raises, a program name Windows rejects is rejected.
Any edit to guest.py made a new state (76 to 145 s). The state now follows
the command line of the guest that is saved, with the paths as
placeholders, so an edit to the rest of guest.py does not.
komorebic state can print something else while the daemon is busy or in
the middle of a monitor change. The runner crashed on it (a hotplug run
did); now it is a RuntimeError with what was printed, which waits retry.
The runner reads the commit from the binaries' commit file and asks git
whether it contains the fix of the bug a marker is for, so the same runner
tests a branch with the bug and one without it.
With two windows on the second display, its mode is changed to two others
and back: the daemon's monitor follows, the windows stay inside the work
area and apart, and return to where they were. A draft for a shared
scenario.