Move the macOS agent into komorebi-e2e-agent as macos.rs, answering the protocol of protocol.rs
with its own verbs (os_windows, displays, activate, minimize, close, move; a window is found by
its title), and remove the separate komorebi-macos-e2e crate that had copied the protocol. There
is one binary name and one port on every platform, so the host has one client and one description
of the protocol.
AppKit is for the main thread, so the macOS agent serves one connection at a time on it, where
the Windows one serves each on a thread. A spawned program on macOS gets a standard input that
stays open, as the test window leaves when its input closes. The crate is built for macOS and
Windows now and stubbed on Linux, as komorebi-testwin is.
The agent of the Windows guest speaks a line protocol (one JSON request, one JSON answer, raw bytes
after the line for put_file and get_file) that has nothing to do with Windows. Move it into
protocol.rs, with a trait for the verbs a platform adds, so that another platform answers the same
protocol instead of copying it, and the host has one client.
The Windows verbs (os_windows, displays, activate, minimize, close) and the code that reads them
from the session are moved to windows.rs, not changed; the agent still serves each connection
on a thread of its own. What the protocol gains for every platform: an environment and an output
file for a spawned program, a `status` of one, and a `send` to its standard input, which the
Windows agent does not use yet. The port is one for every platform, as the Windows one already was.
A spawned program now gets a pipe for its standard input that the agent keeps open: the test window
leaves when its input closes, which with /dev/null was at once. A new `send` verb writes a line to
it, which is how a scenario gives the window a command (fullscreen, title, resize).
The workspace keeps its list of running applications, and which one is active, up to date from
the main run loop, and the agent waits in accept: it listed the applications of the time it
started and never saw a window that opened later. It now lets the run loop turn before it lists
windows.
An AppKit window of a regular application, so that the daemon sees it as it sees any program: the
same options and standard input commands as the Win32 one (title, colour, size, minimum size,
fixed, late rename, fullscreen as a borderless window over its display, report with the frame in
points from the top left of the main display, close, exit). The main thread runs the event loop
in short turns and takes the lines the input thread queued; the program leaves when its window is
closed. A window class has no meaning on macOS, so --class is accepted and ignored.
The macOS source set now builds the crate; Linux still stubs it.
The test window of the e2e suite is a Win32 program whose command line (--title, --class,
--color, --size, --min-size, --fixed, --rename-to, --after) and standard input commands (title,
color, resize, report, close, exit) are the contract every scenario port relies on. Move what
knows no window system into cli.rs, with tests that run anywhere, and the Win32 window into
win32.rs, so that another platform can implement the same window against the same contract.
The Windows window itself is moved, not changed: it reads its options and its commands from
cli.rs now, and the colour is converted to a GDI one where it is used. A fullscreen command is
added to the shared set; on Windows it does what the WM_APP + 2 message does.
The Windows guest has komorebi-e2e-agent; this is its macOS counterpart, speaking the same
protocol (one JSON line per request, raw bytes after it for put_file and get_file) so that the
host client is the same. Beyond exec, spawn and file transfer it answers with the windows the
accessibility API gives (title, frame, focus, minimized) and the displays with their work areas,
and it can activate, minimize, close and move a window.
It has to be started by a program that holds the Accessibility and Screen Recording grants, so
that the daemon it spawns is attributed to that program.
ApplicationIdentifier::Class is described per platform ("Class" on
Windows, "Role or subrole" elsewhere), and the description is taken from
the host the test is built for. every_macos_page_is_as_checked_in renders
the pages of komorebic for macOS from the command line, so on the Windows
runner six of them (ignore-rule, manage-rule, workspace-rule,
named-workspace-rule, initial-workspace-rule and
initial-named-workspace-rule) came out with "- class: Class" and were
reported as stale, though the checked-in pages are right.
The pages are the same on the hosts that have the macOS wording, and the
linux test run checks them, so skip the test on Windows.
The ban (`just lint`, and now the hygiene job) came from the macOS and KDE repositories and was
never applied to the Windows code, so the unified tree had sixteen uses of the macro: seven in
the Windows daemon, six in komorebi-core (written during the unification), one in the KDE
backend and two in the recorder. Each becomes eyre::Report::msg, with format! where the message
has arguments.
The workspace members, the path dependencies, the include_str! and test
fixture paths, the recorder's indexed source keys, and the Nix source
filter and path literals follow the new layout. Cargo.lock is unchanged.
It is a development tool: a bare cargo build leaves it out, publish is off, and no release
ships it. Its manifest uses the workspace dependencies it shares and keeps its own version.
The include_str! and test paths of komorebic (Linux and macOS modules and tests),
komorebi-bar (macOS), komorebi-linux, komorebi-macos, komorebic-core, komorebi-config and
komorebi-bar-core named the old trees (komorebi-for-kde/docs, komorebi-for-mac/docs, the
schema.json files at the roots of the trees, komorebic/fixtures of the macOS tree). They
now read docs/linux, docs/macos, schemas/{windows,linux,macos} and the byte-identical
komorebic/fixtures at the root; the macOS pan tests point at the root fixtures, and
komorebi-linux's config_parity test takes the example config from docs/linux. Comments
that named the old paths were updated with them.
Not touched: markdown docs, justfiles, scripts, tools and nix files that name the old
paths (next revisions of the stack).
Verified: Windows clippy --locked --all-targets -D warnings (default members) passes; on
Linux cargo test -p komorebi -p komorebic -p komorebi-client -p komorebi-linux -p
komorebi-hotkeys -p komorebi-config -p komorebi-bar-core -p komorebic-core -p
komorebi-protocol (one test thread) passes, 96 test binaries ok after config_parity was
fixed; macOS cargo check --target aarch64-apple-darwin (fake CC) passes. Nix not run.
version-linux (komorebi-for-kde/version, shadow-rs 2) and version-macos
(komorebi-for-mac/version, shadow-rs 1) had the same build.rs and the same lib.rs. They
are now one package, crates/komorebi-version (lib name version, shadow-rs from the
workspace), and the KDE and macOS daemons, their command lines and the unified komorebic
depend on it under the key version. The extern crate lines of komorebic/src/main.rs that
renamed the two crates are gone, and the two deny.toml clarify entries name the new
package.
komorebi-daemon/tests/linux_version.rs read the version out of the old crate's Cargo.toml
text, which no longer has a number (it is inherited); it now expects the package version,
which is the workspace version.
Verified: cargo test -p komorebi -p komorebic -p komorebi-client -p komorebi-linux (KDE
side, native Linux) all pass, including the version test; cargo check --target
aarch64-apple-darwin of the macOS packages with the fake C compiler passes. Windows and
nix were not run for this revision (Windows does not use the crate; nix runs at the end of
the stack).
The doc comments that become the description of schema.json and schema.bar.json said
v0.1.42 (Windows), and the macOS views of the schemas said v0.1.0 and linked
komorebi.0.1.0.schema.json. They now say v0.2.0 (the unified release) and link the
0.2.0 file. The macOS site domain in those links is not touched: where the schemas are
published is a release decision.
The checked-in schema.json and schema.bar.json of the Windows tree and of
komorebi-for-mac were edited to match, and the size and hash pins of
crates/komorebi-bar-core/tests/schema_oracle.rs were updated for the two bar schemas
(Windows 248,539 bytes, FNV-1a aaa0fabfb45967b7; macOS 116,925 bytes, a042f6ac063a0cfd).
The KDE schemas carry no version text.
Verified: cargo test -p komorebi-config -p komorebi-bar-core -p komorebi-protocol and
-p komorebi-linux --test schemas pass. The komorebi-config doctest fails to link in
the nix dev shell (it cross-compiles to windows-msvc); that is not caused by this change.
Every package of the workspace now takes its version from [workspace.package]
(version.workspace = true) instead of its own number. The numbers before were
0.1.42 (Windows libraries and packages), 0.1.0 (KDE, the macOS version crate,
komorebi-shortcuts and the e2e guest crates) and 0.1.1 (macOS libraries); the
unified release is 0.2.0 for all of them.
Cargo.lock only changes the version of the workspace's own packages.
Not changed here: the version text in schema doc comments and the generated
schemas (next revision), and the shim packages, which are deleted later and
only pick up the number meanwhile.
Verified: cargo metadata --offline --locked succeeds.
Candidate 9 (draft): wip-u-cmd2 (router gate_message hook + 12 more arms through komorebi_core::command; stacked on wip-u-wm2) with wip-u-mac-wm2 (shared push_simple_rule, macOS ignore-rule fix, Minimize/Close/DebugWindow methods) and wip-u-docs2 (MIGRATION-SUMMARY.md, macos-hand-check-plan.md), all on wip-cand8. Conflicts, if any, are resolved here.
Adds to komorebi_core::command: move_window, focus_window,
cycle_focus_window (layer dispatch: tiling or floating function of the
host), preselect_direction, cancel_preselect, promote_window,
monitor_workspace_index_by_name, focus_named_workspace,
move_container_to_named_workspace(follow), and the three behaviour toggles
(toggle_window_container_behaviour, toggle_cross_monitor_move_behaviour,
toggle_monocle_focus_behaviour). The host traits are WindowCommandHost
(thin forwards to each daemon's direction functions plus
update_focused_workspace_layout) and BehaviourCommandHost (get and set of
three settings). The bodies are the text the router arms have on all three
daemons today. Nothing calls them yet: the daemons converge in the next
three revisions. No behaviour change.
Native tests on the recording stub host, each naming its commands.py
check (mirrors: commands / ...): 5 new tests, komorebi-core commands
test file 23 passed (was 18).
Verified: cargo test -p komorebi-core --features schemars all pass;
clippy -D warnings on komorebi-core all targets passes; format-all
--check clean.
Pure formatting by the same nightly rustfmt invocation the nix fmt check uses (tools/format-all, edition 2024, the tree's rustfmt.toml). No code change. Applied last on the candidate because it touches many files other agents were editing. Verified: tools/format-all --check --tree windows passes afterwards; light gates (fast-check) after all three.
Moves KDE's push_simple_rule (and its test) to komorebi_config::matching: add a simple
rule that matches id as a kind with the legacy strategy unless a simple rule of that
kind and id is there already; a rule of another kind with the same id and a composite
rule do not stop it. The KDE daemon and, next, the macOS daemon use it for the ignore and
manage rules. Nothing calls it yet.
Verified: native cargo test -p komorebi-config 5 + 16 + 9 + 1 passed.
Section 22.1 of core-model.md: KDE and macOS refuse every message before
the router's match while the focused window is not managed
(handle_unmanaged_window_behaviour); Windows gates inside 18 functions.
CommandHost gets a defaulted gate_message(&mut self, &SocketMessage)
that lets everything through (the Windows form, its impl is untouched);
the KDE and macOS impls call handle_unmanaged_window_behaviour and their
routers call the hook where they called the method, so behaviour is
identical per daemon. komorebi-core now depends on komorebi-protocol
(for SocketMessage; Cargo.lock gains that one edge).
This is the groundwork only: the router itself is still per daemon,
because a shared router needs WindowManager<P> in core (see the
struct-move analysis in core-model.md). No BEHAVIOUR change.
Verified: KDE cargo test -p komorebi-linux 670 passed, 0 failed; fake-CC
clippy -D warnings for the four macOS packages passes; cargo clippy -p
komorebi-windows -p komorebi-core --all-targets -D warnings passes;
tools/format-all --check clean. Not verified: KDE VM, macOS hand check
(no behaviour change expected).
Candidate 8 (second draft): cbc40c03 (cand7 + pointer-picks-monitor + thin-events note + bar wgpu fallback + macOS deep dedup) plus wip-u-win-deep (PlatformMonitorId alias, promote_focus_container_idx hook, the WindowManager hook list) and wip-u-fmt (tools/format-all, nix fmt over the nightly rustfmt, deny clarify entries for Windows and KDE). Conflicts, if any, are resolved here.
Candidate 8 (draft): wip-cand7 plus wip-u-deep (which contains wip-u-ptr: shared focus_workspace_number(s), KDE and macOS get the pointer-picks-monitor preamble, the const removed, and the thin-events design note), wip-u-bar4 (eframe wgpu fallback for the Windows bar, scenario rules) and wip-u-mac-deep (ContainerExt removed, nine shared window_manager functions identical on KDE and macOS, five macOS router arms as named methods). Conflicts, if any, are resolved here.
komorebi-core is in the workspace default-members since the review fixes, so a bare clippy --all-targets -D warnings now covers its test files. crates/komorebi-core/tests/commands.rs (wip-u-cmd) had two findings that only show there: an unused Result of new_container_for_window (now unwrap()ed: the stub window cannot fail) and a never-read field pointer_for_all (removed: the Windows switch is tested through the associated const in its own host type). No behaviour change; verified: cargo test -p komorebi-core and the Windows clippy (bare, default-members).
The Windows promote_focus_to_front focused the first column of a custom layout
that has no primary column (first_container_idx(primary_idx().unwrap_or(0)))
where the shared primary_container_idx fails for it; this was one of the
Layout::Custom differences of core-model.md section 18. WorkspacePlatform gets
promote_focus_container_idx(layout) -> usize, defaulting to
primary_container_idx(layout).unwrap_or(0), so a shared promote_focus_to_front
can call it on every platform; the Windows platform overrides it with the exact
expression it had (default layouts 0, custom layouts the first container of the
primary column, else of column 0). window_manager.rs calls the hook. A core test
pins the default for the default layouts.
Not a behaviour change on Windows (the same expression, moved). KDE and macOS
see a new defaulted trait method only. Verified: tools/fast-check native (core
tests), bare Windows clippy -D warnings, KDE check + lib tests, macOS fake-CC
type-check PASS; e2e: commands (promote-focus), layouts (custom layout).
Candidate 7: wip-cand6 plus wip-u-rulematch (one window-rule matcher in komorebi-config), wip-u-stall2 (lock-holder guard, should_manage before the lock, reaper unlock, heartbeat), wip-u-bar3 (bar e2e scenario fix, skip when the guest cannot draw, bar config tests) and wip-u-cmd (komorebi_core::command: 16 shared router arms). Conflicts, if any, are resolved here.
All three daemons now let the pointer pick the monitor for every shared
command that has the preamble, so the const has no reason left. The
shared functions always call focus_the_monitor_under_the_pointer; the
three CommandHost impls lose the const (Windows had it true already, so
nothing changes there). The core test of the switch becomes
the_pointer_picks_the_monitor_..._on_all_platforms. known-issues item 1
is marked resolved and core-model.md section 18 text is updated.
No behaviour change in this revision beyond the previous two.
Verified: komorebi-core tests all pass (command tests 18); KDE cargo test
-p komorebi-linux 670 passed, 0 failed; fake-CC clippy for the four macOS
packages passes; cargo clippy -p komorebi-windows --all-targets -D warnings
passes. Not verified: Windows tests or e2e (cannot run on Linux).
komorebi-core gets pub type PlatformMonitorId<P> = <P as MonitorPlatform>::Id,
the monitor counterpart of PlatformWindowId (blocker 5 of core-model.md
section 18). The Windows daemon aliases it (window::PlatformMonitorId, the
shared MonitorId) and gets window::monitor_id_at_cursor() like KDE's, so
monitor_idx_from_current_pos reads: ask the monitor id at the cursor, compare
monitor.id == monitor_id, and only then the Windows-only stale-handle fallback
(WindowsApi::monitor(monitor_id.to_hmonitor())). Same calls as before
(cursor_pos, monitor_from_point), in the same order.
Not a behaviour change. kfde: the alias is generic over MonitorPlatform; KDE and
macOS can alias it the same way. Verified: tools/fast-check native (core
tests), bare Windows clippy -D warnings, KDE check + lib tests, macOS fake-CC
type-check PASS; e2e: commands (monitor-from-cursor commands), hotplug scenarios
if any.
Adds four tests to crates/komorebi-config/tests/rule_matching.rs next to
the KDE/macOS ones moved there: a Windows exe rule names the program with
its extension (mirrors rules_exe, where platform.exe_id adds `.exe` on
Windows) and the id without it does not match; a regex id is looked up as
written on Windows and with `.exe` removed elsewhere; the whole grid of
kinds x strategies x ids agrees between RuleQuirks::WINDOWS and UNIX for a
window with one class (mirrors rules_class); a negated class rule for a
window of another class and for one with no class. Each names the e2e
check it mirrors. docs/dev/e2e-to-unit.md points at the shared file.
Verified: cargo test -p komorebi-config --test rule_matching (16 passed);
bare cargo clippy --locked --all-targets -D warnings clean.
The Windows gate showed that the bar cannot open a window in the golden
guest (no OpenGL 2.0: "egui_glow requires opengl 2.0+"). The scenario now
reads the bar's own output (`classify`): that exact failure turns the
window, stays-alive and daemon-restart checks into visible
`skipped: guest has no OpenGL 2.0` lines (counted in `result.json` and
printed as `skipped: N` by the runner); the schema equality, "the bar reads
its configuration" (real: the configuration is parsed before the window),
`komorebic state` and `stop --bar` stay checks; any other early exit of
the bar (a configuration error, a panic) is a failure with the bar's
output in the message, and a bar that opens its window gets the full walk as
before. Unit tests for `classify` run with the runner tests.
komorebi-bar-core gets tests/config.rs: windows-only widgets and the `mouse`
block are accepted on every platform, `supported()/unsupported()/enabled()`
name and skip what the platform cannot run (D-coord-1), a Command mouse
message is a plain string and the tagged form is rejected (the e2e finding),
the network widget accepts `default_interface_options` and the old key
names, layouts read from their names, `KomobarConfig::read` fills the frame
and refuses a non-json file. The warning text itself is not asserted (no
tracing subscriber in the core).
docs/dev/bar-e2e.md records the limitation and an analysis of getting
rendering into the guest (wgpu with the WARP adapter recommended; a mingw
Mesa is not offered by nixpkgs); nothing was added.
Verified: runner and library tests (161 passed), ruff clean on the scenario
(three older findings in other files are not mine), bar-core native tests 3
unit + 7 oracle + 6 config. Windows clippy and the macOS check: see the
report. The scenario itself was not run.
Merge of wip-cand5, wip-u-bugfix, wip-u-wm, wip-u-settings3, wip-u-repotools,
wip-u-nix3 and wip-u-e2e2unit.
Resolutions:
- docs/dev/macos-handcheck.md: every section is kept, in order. The bugfix
agent's section F (bar clicks) and the settings agent's section (also
headed F) both appended after E; the settings one is renamed G, text
unchanged.
- komorebi-for-mac/komorebi/src/animation/mod.rs and static_config.rs: the
formatting-only revision of wip-u-nix3 (76ab52da, import order) conflicts
with the semantic edits of wip-u-settings3 (S4/S5). The files are taken
from wip-u-settings3 as they are; the following style(macos) revision
formats them again with the check's rustfmt invocation.
Verified: see the following revisions and the report.
komorebi_core::command gets focus_workspace_number (show a workspace unless
it is in front) and focus_workspace_numbers (show it on every other monitor,
then on the focused one), both with the pointer preamble when the host's
POINTER_PICKS_THE_MONITOR_FOR_ALL says so, over a new CommandHost method
show_workspace_on (focus the workspace of a monitor and load it, which the
daemons already did inline). The three daemons' arms call them (Windows keeps
its focus_workspace_numbers method as a wrapper) and implement
show_workspace_on. The const is unchanged: true for Windows, false for KDE and
macOS, so nothing changes yet; the next revisions flip it. Tests: the
Windows-switch test becomes a test of all five commands with the switch off and
on, and focus_workspace_number(s) are tested on the stub host (commands.py:
focus-workspace, focus-workspaces).
Verified: cargo test -p komorebi-core --features schemars --test commands: 18
passed; KDE cargo test -p komorebi-linux (lite env): 666 passed, 0 failed; fake-CC cargo
clippy -D warnings on the macOS packages: PASS; Windows cargo clippy -p
komorebi-windows --locked --all-targets -D warnings: PASS. Not run: Windows
tests, VM and Mac.
Convenience for the callers that have a workspace and no platform type to name
(the window manager functions, which are the same text on KDE and macOS): the
same as P::hide_spot(self) and P::hide_spot_on_display(self). Nothing calls them
yet in the KDE and Windows daemons; no behaviour change.
Verified: native cargo test -p komorebi-core passes; fast-check all trees PASS.
wip-u-coretests (written against the hook's old name after_floating_removed) and wip-u-core4 (which renamed it to before_floating_removed because it runs before the window leaves the ring) were merged in candidate 5; the stub platform and the expected hook logs now use the new name. No behaviour change: the order test already pinned 'before the removal'. Verified: cargo test -p komorebi-core (with and without the schemars feature).
KDE's should_act and should_act_individual become thin wrappers over
komorebi_config::rules (RuleQuirks::UNIX: a `.exe` in a rule id is
ignored, as before); their signatures and the should_act_window wrappers
are unchanged, so no call site moves. The 12 pure matching tests of
komorebi-for-kde/komorebi/tests/rule_matching.rs move to
crates/komorebi-config/tests/rule_matching.rs with their assertions
untouched (they call same-signature local wrappers over the shared
function); the manage-rule rescue test, which needs the fake backend, stays
in the KDE file.
No behaviour change: the function bodies were identical (docs/dev/
rule-matching.md). Verified: cargo test -p komorebi-config --test
rule_matching (12 passed); KDE cargo test -p komorebi-linux --lib (292
passed) and --test rule_matching (1 passed), command_sweep, rules; cargo
check --all-targets clean. KDE clippy -D warnings fails on 4 pre-existing
lints in process_command.rs and kwin/mod.rs (not touched here). Not run:
VM suites.
Candidate 5: wip-cand4 plus kfw's review fixes (wip-u-fix5: revert of the subscriber write timeout and the hwnd writer thread, BAR_RUNNING tied to the message, dead-window HIDDEN_HWNDS cleanup, core in default-members), kfm's macOS registry fixes (wip-u-kfm3), kfde's hook rename and per-pass title-bar snapshot (wip-u-core4), the komorebi-core characterization tests (wip-u-coretests) and the docs (wip-u-docs). Conflicts, if any, are resolved here.
The Windows e2e scenarios layouts (111 checks), flipping, layout_flip, padding,
closing, minimizing, floating, stacks, tiling and tiling_off assert where the
tiles of a workspace are. Since the consolidation every daemon gets those tiles
from komorebi-core's Workspace::update_shared, so they can be checked on the
stub platform on Linux (and on the Mac Mini for macOS) instead of in a guest.
crates/komorebi-core/tests/e2e_layouts.rs (6 tests) runs update_shared on a
StubPlatform workspace for the 8 layouts of the scenario, 1 to 8 containers and
three padding settings: one tile per container, inside the work area, not on
each other; workspace padding moves tiles 40 px in, container padding shrinks
every tile, and back as it was; each of the three flips equals the plain tiles
mirrored (as a set); removing a container (what a closed, minimized or floated
window does) leaves the others at least as much room; two containers, one a
stack of two, are two tiles; with tiling off nothing is placed in any layout.
Each test names the e2e checks it mirrors. They protect Windows, KDE and macOS
alike. Platform dependent: the stub adds no border and no frame adjustment, so
the Windows border of 7 px (windows_padding) and each daemon's own
adjust_layout stay e2e only, as does the OS frame matching the tile.
Verified: cargo test -p komorebi-core --test e2e_layouts, 6 passed (native
Linux; macOS crates run later on the Mini). No source change, no bug found.
komorebi_config::rules holds should_act and should_act_individual, the
evaluation of MatchingRule/MatchingStrategy against a window
(RuleSubject: title, exe_name, classes, path). The body is the KDE/macOS
copy moved verbatim; the single difference of the Windows copy (a rule id
is compared as written, no `.exe` stripping) is RuleQuirks::WINDOWS vs
RuleQuirks::UNIX, and Windows' single class is a one-element slice. The
regex cache is passed in (the daemons keep REGEX_IDENTIFIERS and its lock
order). regex 1 becomes a dependency of komorebi-config (already in the
lock; one Cargo.lock line).
Nothing calls it yet, so no daemon behaviour changes. Verified: cargo
clippy -p komorebi-config --all-targets -D warnings, fmt check.
komorebi_core::set_container_locked is the body of the
LockMonitorWorkspaceContainer and UnlockMonitorWorkspaceContainer arms
(the two differ by the flag; the text is the same on all three daemons),
over a third small host trait ContainerCommandHost: CommandHost that has
monitors_mut. Tests: lock then unlock, a container index that is not there
is ignored and a missing monitor or workspace is an error.
Verified: cargo test -p komorebi-core --features schemars --test commands
(native): 16 passed, 0 failed. Not run: the daemons.
Follow-up to the review of komorebi-core (S/review/core.md, F2 and F4 and its
untested-behaviours list); most of the list was already pinned, this adds the rest:
- the after_floating_removed hook is pinned to run BEFORE the window is taken out
(it sees both windows and the old focus index), today's KDE/macOS order, although
the trait doc says after; the stub now logs len and focus for the hook.
- resolve_placement_index with Rules maps (Single and Many matching, Secondary,
no match falls back after the focused container); the stub gained a match id and a
path (a window without a path never matches Rules: it falls back).
- the JSON key set of a default workspace, and of Windows and macOS monitors per extra.
- the documented defaults of every optional hook on a platform that overrides nothing
(the KDE-shaped test platform), and that the default place hooks make update_shared fail.
- Monitor remove_workspace_by_idx at the length, and an old monitor file with a
non-empty ring of workspaces missing optional keys.
Verified: cargo test -p komorebi-core 215 passed, 1 ignored (the known bug), and with
--features schemars 217 passed, 1 ignored; clippy --all-targets has no warning in the
crate. No non-test source changed.
The update widget's refresh thread polled the Windows repository's GitHub
API on every platform (a hard-coded second URL, while the first fetch went
through BarPlatform::latest_release_api_url), and the page the click opens
was built for the Windows repository, so on macOS the widget compared the
mac version against Windows releases after the first refresh and linked to
the wrong project.
The refresh now uses latest_release_api_url, and a new
BarPlatform::release_page_url(version) builds the click target: Windows
keeps https://github.com/LGUG2Z/komorebi/releases/v{version} exactly,
macOS gets https://github.com/LGUG2Z/komorebi-for-mac/releases/tag/v{version}.
BEHAVIOUR (macOS): the update widget compares against and links to the
komorebi-for-mac releases. Windows output is unchanged (same URLs). Gate:
macOS hand-check (see docs/dev/macos-handcheck.md); Windows needs no e2e.
Verified: see the following revisions' fast-check results; not run on a Mac.
Pure formatting, no other change: taplo fmt (default configuration, taplo
0.10.0) over the manifests that the kfm toml-fmt check reported as not
properly formatted: crates/komorebi-bar-core, crates/komorebi-protocol,
komorebi-client, komorebi-daemon, komorebi-for-mac/komorebi and
komorebi-for-mac/komorebic. The other 19 files that check lists were
already clean.
Effect on other platforms: the first four are Windows manifests and
komorebi-protocol is also in the KDE closure. crane's dependency derivation
contains the manifests, so the Windows and KDE dependency derivations and
checks change once with this revision (one cold rebuild of the
dependencies, then stable again).
Verified: taplo fmt --check over the 25 files of the check passes after it
(it failed on exactly these six before).
The commands e2e scenario learns that a command does not exist in a platform only
by running it in a guest (error: unrecognized subcommand, skipped with its name),
about 7.6 minutes per Windows run.
crates/komorebic-core/tests/e2e_sweep.rs reads SWEEP and PRINTED out of
e2e/lib/komorebi_vm/core/scenarios/commands.py (skipped when the e2e library is not
in the source tree) and parses each line with the platform's clap command: every
one is a command of the Windows komorebic, and the macOS one lacks exactly the
eight the scenario would skip there (focus-follows-mouse enable/disable, the
Windows implementation of toggle-focus-follows-mouse, toggle-maximize, the
transparency commands). 3 tests. mirrors: commands / <command> (the command is
understood, for the command line only).
Stays e2e only: that the daemon then answers; the KDE komorebic's own command set.
Verified: cargo test -p komorebic-core --test e2e_sweep, 3 passed (native Linux;
platform independent). No source change.
Pins the cost rule the macOS fix depends on: Registry::insert of a new id runs no
handle's drop, a replaced handle is handed back and dropped only when the
caller drops it, get drops nothing, and remove hands the handle back. A probe
handle counts its drops.
Verified: native cargo test -p komorebi-backend: 40 unit, 7 doc, 1 compile_fail
passed, 0 failed.
tests/state_roundtrip.rs (15 tests) reads the monitors of the e2e fixtures
(Windows kfw-tiled, kfw-stack, kfw-float; KDE kfde-tiled, kfde-stack) into the
shared Monitor<P> with a platform shaped like each daemon (Windows: isize id,
optional serial number, the name/device_id/workspace_names extra; KDE: u32 id,
string serial number, no extra; macOS: window_hiding_position extra), writes
them again and compares the parsed JSON: every fixture is written as it was
read. Also pins that the corner is the last macOS monitor key and cannot be
omitted, that the workspace keys are the same whatever the platform, the exact
set of KDE monitor keys, and which keys an old state file may omit (23 optional
keys at monitor, workspace and container level, e.g. container locked and
workspace layout_options_rules) and which it may not (18 required keys,
including layer, work_area_offset_rules and apply_window_based_work_area_offset:
a file from before those existed does not load; pinned, not judged).
The fixtures are copied into tests/common/fixtures.rs as Rust text because the
nix source filters keep .rs files and drop .json; a test compares the copies with
e2e/lib/tests/fixtures when the checkout has them. The macOS fixture is NOT real
macOS output: it is kfde-tiled reshaped with jq to the macOS window and monitor
shape of the state_pin tests (no Mac here), and says so in its comment; replace
it with 'komorebic state' from a Mac when one is at hand.
Verified: cargo test -p komorebi-core (27 unit + 179 integration passed, 1
ignored) with and without --features schemars; cargo clippy -p komorebi-core
--all-targets has no warning in the crate. Windows clippy and macOS check not run:
the tests are portable crate tests and no platform source changed.
LGUG2Z