On the Mac Mini native clippy -D warnings failed in the macOS bar module with three findings that the fake-CC
check only printed as warnings: the re-exports of ICONS_CACHE and ImageIconId in macos/widgets/mod.rs are
unused (they were pub items of the crate root before the module move, which the lint does not flag),
and Stroke::new(1.0, ...) in macos/widgets/komorebi.rs:393 falls back to f32. The two re-exports are removed
(grep: nothing in the macOS module uses them; the Windows module does and keeps them), the literal is
1.0_f32 (the type it already had). The same sweep removed the #[allow(unused_imports)] re-export of
rgba_to_color_image, also unused on macOS. Remaining pub use lines (render, selected_frame, ui, statics,
Alignment) are used. Behaviour identical.
Gates run: macOS fake-CC check of komorebi-bar and komorebi-bar-macos --all-targets: no warning left in the
bar; Windows clippy -D warnings PASS; S/bar2 schemas byte-identical. Not run: native macOS clippy (the Mini).
wip-u-kfm carries the macOS clippy fixes (&Path, drain, filter, slice fill, sort_by_key, collapsible_match allows, capture_spike, bar stroke literals). The bar stroke literal revision touches komorebi-for-mac/komorebi-bar, which the migration moved to komorebi-bar/src/macos; conflicts are resolved here by applying the same edit at the new paths.
Adds a status section to the hand-check list: cargo test --workspace passed
on the Mini (daemon 366 passed, 1 ignored) and clippy is clean, but nothing
was run as a daemon, so every walk-through item stays open.
Verified: documentation only.
Six literals in the macOS bar (applications.rs, komorebi.rs x3, komorebi_layout.rs,
time.rs) passed 1.0 to egui's Stroke::new, which rustc 1.99 reports as an f32
fallback (a future hard error). The Windows bar and komorebi-bar-core
already say 1.0_f32 for the same calls, so this makes the macOS bar text
match them; the value is the same f32. No behaviour change.
Verified: fake-CC cargo clippy --locked --target aarch64-apple-darwin
--workspace --all-targets -D warnings: clean (whole workspace). The Windows
bar and komorebi-bar-core are untouched. Verified on the Mini: not yet.
examples/capture_spike.rs iterated bytes.chunks_exact(4), which clippy flags
as chunks_exact_with_const_size on 1.93 and as chunks_exact_to_as_chunks on
1.99 (the allow name differs between the two, so an allow cannot serve
both). chunks(4).filter(len == 4) visits the same full pixels in the same
order and still drops a trailing partial one; the spike is an example
binary, not the daemon. No behaviour change.
Verified: fake-CC cargo clippy --locked --target aarch64-apple-darwin
--workspace --all-targets -D warnings: clean (whole workspace). Verified on
the Mini: not yet.
The Mac Mini run failed on -p komorebi: the daemon packages are komorebi-macos and komorebi-windows (the
single komorebi package is step 8). Corrected the command list and the note.
clippy::match_like_matches_macro (-D warnings, seen by native clippy on the Mac Mini) flagged the match
with a Keyboard/Media/Systray arm of cfg!(target_os = "windows") and a true arm. The same boolean is
written !matches!(self, Keyboard | Media | Systray) || cfg!(target_os = "windows"): false only for those
three variants off Windows. Behaviour identical.
Gates run: Windows clippy -D warnings PASS; native cargo clippy -p komorebi-bar-core --all-targets -D
warnings PASS; bar-core tests (3 unit + 6 oracle) PASS; macOS fake-CC check PASS.
Marks the bar steps as executed (B4 left, why), and lists the cargo build, clippy, test and schema commands
for aarch64-darwin per revision. Not verified: any of them on a Mac.
The macOS bar module moves from komorebi-for-mac/komorebi-bar/src/macos to komorebi-bar/src/macos (the
include_str! path follows), komorebi-bar/src/main.rs is a cfg_select! over target_os that runs
windows::main or macos::main, and komorebi-bar/Cargo.toml has what both share in [dependencies] and the
rest in per-target tables (Windows: windows, windows-core, windows-icons x2, systray-util, tokio, regex,
which, egui_extras, netdev 0.46, sysinfo 0.39, komorebi-themes without default features; macOS: objc2,
objc2-app-kit, icns, raw-window-handle, netdev 0.40, sysinfo 0.38, komorebi-themes with defaults), so each
platform keeps the versions it had. The old komorebi-bar-macos package stays as a shim that includes the
moved module. The macOS flake builds -p komorebi-bar and its source filter takes the unified package's
manifest, main.rs and src/macos; the Windows filter leaves src/macos out. The bar does not build for
Linux (no arm of the cfg_select), as before.
Gates run: Windows clippy --all-targets -D warnings PASS; macOS fake-CC check --locked --all-targets of
-p komorebi-bar and -p komorebi-bar-macos PASS (type check only); bar-core schema oracle (3 + 6) PASS; the
S/bar2 harness regenerates schema.bar.json for Windows (9091 lines) and macOS (3774) byte-identical to the
checked-in files; tools/kde-closure-check ok; CLI docs oracle identical x3; nix evaluation PASS and by
evaluation an edit of komorebi-bar/src/windows changes the Windows derivations only (the macOS side cannot
be evaluated on this Linux host). Not run: nix builds, any bar run (Windows screenshot gate and the Mac
hand check are owed).
komorebi-for-mac/komorebi-bar/src/{bar,config,os}.rs and widgets/ move to src/macos/, main.rs to
macos/mod.rs (pub fn main); src/main.rs is a caller. Mechanical edits only: crate:: becomes
crate::macos:: (all sites), the include_str! path gets one more ../, and the unused root re-export of
komorebi_bar_core::platform is dropped.
Gates run: macOS fake-CC check of komorebi-bar-macos --locked --all-targets PASS (type check only); bar-core
schema oracle PASS; S/bar2 harness regenerates both bar schemas byte-identical to the checked-in files
(macOS 3774 lines, Windows 9091). Not run: any bar run on a Mac (the user's Mac check).
komorebi-bar/src/{bar,config,os}.rs and widgets/ move to komorebi-bar/src/windows/, main.rs to
windows/mod.rs (pub fn main); src/main.rs is a four-line caller. Mechanical edits only: crate:: becomes
crate::windows:: (all sites), the include_str! path gets one more ../, and the unused root re-export
of komorebi_bar_core::platform is dropped (the main installs the platform by its full path). This
prepares one package with a module per platform; behaviour is the same code.
Gates run: Windows clippy --all-targets -D warnings PASS; bar-core schema oracle (3 unit + 6) PASS; the
S/bar2 harness (real bar sources, regen.sh, updated to read src/windows) regenerates schema.bar.json for
Windows (9091 lines) and macOS (3774 lines) byte-identical to the checked-in files; tools/e2e-needed
says the bar is not an input of the e2e binaries. Not run: the bar itself, the screenshot gate (owed).
The KDE twin of the macOS fix: the trait declarations of preload, postload
and reload (static_config.rs:726, :732, :735; the impls follow) took
&PathBuf, introduced by the same step 3 conversion to the extension trait.
read takes &Path since the config-crate revision; the one clone of the path
is path.to_path_buf(). No behaviour change.
Verified: native cargo clippy --locked -p komorebi --all-targets -D warnings
in komorebi-for-kde: clean (the 3 ptr_arg errors that predated the backend
work are gone); cargo test --locked -p komorebi --lib: 294 passed, 0 failed.
komorebi-for-mac/komorebi-bar depends on komorebi-client (the one package, path ../../komorebi-client)
instead of komorebi-client-macos; same module, same API. Cargo.lock only rewires that edge.
Gates: macOS fake-CC check of komorebi-bar-macos --locked --all-targets PASS (type check only); bar-core
schema oracle (cargo test -p komorebi-bar-core: 3 unit + 6 oracle) PASS. Not run: any bar run.
monitor.rs (two ifs that choose where a moved container goes, inside a match
on the layout) and static_config.rs handle_asc_file (a 40-line block under
the extension check). The lint wants the if folded into the outer match
arm as a guard; doing that restructures the arms (the else branches become
extra arms) without changing what they do, which is more edit than a lint
fix should be and cannot be run here, so each site gets an allow with a
comment instead. No behaviour change. Pre-existing on the original macOS
tip 9a58e511.
Verified: fake-CC cargo clippy --locked --target aarch64-apple-darwin -p komorebi --all-targets -D warnings: the daemon lib and its tests are clean with the six hygiene and ptr_arg revisions applied (the whole-workspace run still reports newer-clippy lints that the Mini's 1.93 does not have: the bar's f32 literal fallback and examples/capture_spike.rs chunks_exact). Verified on the Mini: not yet.
window_manager.rs sorted (usize, Layout) pairs by their first field with a comparator closure; sort_by_key on the same field is the same stable sort.
No behaviour change. Pre-existing on the original macOS tip 9a58e511 (reported by cargo clippy --all-targets -D warnings on the Mini, stable 1.93).
Verified: fake-CC cargo clippy --locked --target aarch64-apple-darwin -p komorebi --all-targets -D warnings no longer reports this lint (the last hygiene revision records the whole run). Verified on the Mini: not yet.
window_manager.rs reset every entry of workspace.resize_dimensions in a for loop; fill(None) does the same.
No behaviour change. Pre-existing on the original macOS tip 9a58e511 (reported by cargo clippy --all-targets -D warnings on the Mini, stable 1.93).
Verified: fake-CC cargo clippy --locked --target aarch64-apple-darwin -p komorebi --all-targets -D warnings no longer reports this lint (the last hygiene revision records the whole run). Verified on the Mini: not yet.
window.rs WindowInfo::from(&CFDictionary) spelled filter by hand with and_then; an empty name is still None.
No behaviour change. Pre-existing on the original macOS tip 9a58e511 (reported by cargo clippy --all-targets -D warnings on the Mini, stable 1.93).
Verified: fake-CC cargo clippy --locked --target aarch64-apple-darwin -p komorebi --all-targets -D warnings no longer reports this lint (see the last hygiene revision for the whole run). Verified on the Mini: not yet.
monitor.rs remove_workspaces moved every workspace into a new VecDeque through drain; mem::take moves the whole deque and leaves an empty one, which is the same result without the second allocation.
No behaviour change. Pre-existing on the original macOS tip 9a58e511 (reported by cargo clippy --all-targets -D warnings on the Mini, stable 1.93).
Verified: fake-CC cargo clippy --locked --target aarch64-apple-darwin -p komorebi --all-targets -D warnings no longer reports this lint (see the last hygiene revision for the whole run). Verified on the Mini: not yet.
Fixes the 3 new lints at static_config.rs:719, :726 and :729 (the trait
declarations of preload, postload and reload; the impls follow). They were
introduced by kvtvnouo, 'refactor(mac): use StaticConfig and its family of
komorebi-config', which turned the inherent methods into the extension
trait; the original tip 9a58e511 did not have them. read gets a &Path
through the previous revision, and the one clone of the path (the
ReloadStaticConfiguration message) is path.to_path_buf(). No behaviour
change.
Verified: macOS fake-CC type-check (tools/fast-check) PASS, and fake-CC
cargo clippy -p komorebi --all-targets -D warnings no longer reports the
three. Verified on the Mini: not yet (cargo clippy --all-targets -D warnings).
clippy::ptr_arg: the function only opens the file, so any path will do, and
every caller that passes a &PathBuf still compiles through deref. Needed so
the macOS StaticConfigExt methods can take &Path (next revision).
Verified: fast-check native, Windows clippy -D warnings, KDE check and lib
tests, macOS fake-CC type-check PASS. Verified on the Mini: not yet.
Updates docs/dev/unified-binaries.md: steps 5 and 6 done, the limits found, step 7 for the bar written as
exact steps (B0-B4, not executed; bar files untouched), and the list of heavy builds, VM, e2e and Mac
checks the coordinator owes. Not verified: any nix build.
The root komorebi-client package (0.1.42) is the one client: src/lib.rs is a cfg_select! over target_os
that re-exports the module of the platform. The three lib.rs files move to komorebi-client/src/{windows,
linux,macos}.rs (they were made equal in socket code by the previous revision), the KDE integration tests to
tests/linux_{daemon,subscribe}.rs (#![cfg(target_os = "linux")]). The daemon crate of each platform has a
dependency key of its own (cargo allows one path per key) and the module names it (use crate::komorebi_linux
as komorebi). The old komorebi-client-linux and komorebi-client-macos packages stay as shims that include
the moved module, so the old names build until the cutover (the macOS bar and komorebic-macos still use
them). komorebic now depends on the one komorebi-client on all three platforms. The KDE and macOS flakes
build the unified client (-p komorebi-client) and take its manifest, lib.rs and their module in the source
filter; the Windows filter leaves the other platforms' modules and tests out. Windows API for komorebi-bar,
komorebi-gui and komorebic is unchanged.
Gates run: Windows clippy --all-targets -D warnings PASS (client, bar, gui, komorebic); KDE cargo test -p
komorebi-client -p komorebi-client-linux -p komorebic -p komorebi-linux: 775 passed 0 failed (the client
tests and doctests included); cargo check of komorebic-linux and komorebi-client-linux PASS; macOS fake-CC
check --locked of komorebi-client, komorebic, komorebi-client-macos, komorebi-bar-macos, komorebic-macos
--all-targets PASS (type check only); CLI docs oracle byte-identical x3; nix evaluation PASS; by evaluation an
edit of komorebi-client/src/windows.rs changes only Windows derivations, linux.rs only kfde, macos.rs
neither. Not run: nix builds, the e2e (komorebi-client is in the closure of komorebi.exe's users: Windows e2e
OWED), any macOS link or run.
Windows and macOS had a Connection (messages written a line each in order); KDE had none, and Windows
opened it differently from macOS. All three now have the macOS text (open -> from_stream; KDE's with docs),
and the Windows DATA_DIR is exported like the other two. Additive on KDE and Windows, no change to what
any function does. Preparation for one komorebi-client package; the socket functions were already identical.
Gates run: Windows clippy --all-targets -D warnings PASS (client and its users); KDE cargo test -p
komorebi-client-linux (unit, integration, doctests) PASS. Not run: macOS (file untouched).
komorebi-for-mac/komorebic/src/main.rs and applications.json move to komorebic/src/macos/{mod.rs,
applications.json}; only the include_str! paths change (they point into komorebi-for-mac/docs) and
main is pub. The old package komorebic-macos stays and builds from the moved file through a shim
(src/main.rs includes ../../../komorebic/src/macos/mod.rs). komorebi-for-mac/komorebic/fixtures stays
where it is: the macOS daemon's pan tests read it. The macOS flake builds komorebic (unified) instead of
komorebic-macos and its source filter takes the unified package's manifest, build.rs, main.rs and
src/macos; the Windows filter already leaves macos out.
Gates run: macOS fake-CC check --locked of -p komorebic and -p komorebic-macos PASS (type check only);
Windows clippy PASS; KDE check PASS; CLI docs oracle byte-identical x3 (the macOS harness reads
komorebic/src/macos/mod.rs now); nix evaluation PASS, and by evaluation an edit of komorebic/src/windows.rs,
linux/mod.rs or macos/mod.rs changes only its own platform's derivations. Not run: nix builds, any macOS
link or run (the user's Mac check: komorebic --help, --version, quickstart, start, stop).
komorebi-for-kde/komorebic/src/{main.rs,hotkeys.rs,applications.json} and tests/{check,cli,hotkeys}.rs
move to komorebic/src/linux/{mod.rs,hotkeys.rs,applications.json} and komorebic/tests/linux_*.rs
(#![cfg(target_os = "linux")]). The only edits are paths: include_str! and the tests' fixture and
repository-root paths point into komorebi-for-kde/ (docs, komorebi-hotkeys, schema files),
komorebi/tests/asc.rs reads the moved applications.json. The old package komorebic-linux stays and
builds from the moved file through a shim (src/main.rs includes ../../../komorebic/src/linux/mod.rs), so
the old name works until the cutover; its tests now run in the unified package. The KDE flake builds and
tests komorebic (unified) instead of komorebic-linux, its source filter takes the unified package's
manifest, build.rs, main.rs, src/linux and tests/linux_*; the Windows source filter leaves the Linux
and macOS files out. Comments and docs that name komorebic/src/main.rs or komorebic/tests/*.rs
(check.rs, ARCHITECTURE.md, scripts/compare-gen.py, the VM check suite) were not touched: they would
change the KDE derivations for text only.
Gates run: KDE cargo test -p komorebi-linux -p komorebic -p komorebic-linux -p komorebi-client-linux
-p komorebi-hotkeys --no-fail-fast: 888 passed, 0 failed (the moved komorebic tests included); Windows
clippy -D warnings PASS; macOS fake-CC check PASS; fast-check nix evaluation PASS; CLI docs oracle for
kde now generated by the unified komorebic: 166 pages, 0 diff, and its --help first line and --version
equal the old package's. Not run: nix builds (the KDE derivations changed), VM suites. Note: cargo
build/test of both komorebic and komorebic-linux in one command writes the same binary name twice
(use one of them).
The unified komorebic package has one Cargo description, and the three CLIs read their about text from
env!("CARGO_PKG_DESCRIPTION"), so the Windows, KDE and macOS help would all have said the same. The text
is a literal in each platform module now, the one the old package had. Verified: see the next revisions
(komorebic --help of the unified Linux binary equals the old komorebic-linux one).
Adds the state, the measured cache isolation after the workspace merge and the limits found (stubbed
source is read at evaluation, so other systems' attributes need their own builder; deny/fmt/taplo of the
merged workspace unbuilt; steps 5 and 6 left for the cutover). Not verified: any nix build.
The root komorebic package (version 0.1.42) is now the one komorebic: src/main.rs is a cfg_select! over
target_os that runs the CLI module of the platform. The Windows main is moved to src/windows.rs
(pub fn main); the Linux and macOS CLIs are included from where they live
(#[path = "../../komorebi-for-kde/komorebic/src/main.rs"], likewise macOS), so no file moves yet and
the old komorebic-linux and komorebic-macos packages still build from the same files. Dependencies are
in per-target tables; cargo allows one path per dependency key, so the Linux and macOS crates keep
their renamed keys and main.rs aliases them (extern crate komorebi_client_linux as komorebi_client).
The unified package needs no reqwest build dependency (committed applications.json) so it builds
natively on Linux without openssl. hotkeys.rs: crate::HOME_DIR -> super::HOME_DIR (same crate root in
the old package).
Gates run: Windows clippy --all-targets -D warnings PASS; KDE check + 294 lib + 5 schemas (old package)
PASS; macOS fake-CC check of -p komorebic --target aarch64-apple-darwin --locked --all-targets PASS (type
check only); native Linux cargo check/build of -p komorebic PASS and its docgen output is byte-identical
to the KDE oracle (166 pages, diff 0); CLI docs oracle byte-identical for windows, macos, kde
(S/step4/regen.sh reads komorebic/src/windows.rs now); nix eval of komorebic and the kfde packages OK.
Not run: nix builds, e2e (komorebic.exe inputs changed: Windows e2e gate OWED), any macOS link or run
(the user must check on a Mac: komorebic --help, --version, start, stop, state, docgen output).
The three flakes now build from the one root Cargo workspace (previous revision, which must land with
this one). nix/workspace-src.nix assembles each platform's source: the files it needs (its crates, the
root crates they depend on, the root Cargo.toml and Cargo.lock) plus a stub (the member's own
manifest, an empty lib.rs, a main that does nothing) for every other member, because cargo has to load
the whole workspace but must not depend on the other platforms' code. The KDE and macOS flakes pass
-p <their packages> (cargoExtraArgs), no longer cd into a subdirectory workspace, use the root
Cargo.lock/Cargo.toml (vendored from the filtered source, so crane does not read the stubbed one),
and run cargo deny with --workspace --exclude <the other platforms' packages> and their own
deny.toml; the root flake excludes the KDE and macOS packages from deny and builds default-members.
komorebic/applications.json is added to the macOS source filter (it is embedded by include_str!).
The KDE/macOS deny.toml clarify entries and root deny.toml follow the package renames (squashed into
the rename revisions).
Evaluation (nix eval drvPath, no build): Windows clippy, deny, fmt, nextest, toml-fmt; kfde clippy,
doc, deny, fmt, toml-fmt, nextest, schema-fresh; kfde-komorebi, kfde-komorebic, komorebic. Cache
isolation measured by evaluation: an edit of crates/komorebi-bar-core or komorebi/src changes the
Windows drvs and leaves the kfde clippy and nextest drvs unchanged; an edit of komorebi-for-kde changes
kfde and leaves Windows unchanged; an edit of komorebi-for-mac changes neither. tools/kde-closure-check
ok (rewritten for the merged workspace), root-crates.json unchanged.
KNOWN LIMITS: (1) the stubbed source is a derivation that crane reads at evaluation (readDir in
mkDummySrc), so evaluating or building another system's attributes needs a builder for that system:
`nix flake show --all-systems` and drvPath of aarch64-darwin attributes now fail on a Linux host (the
fast-check nix step evaluates the current system only). (2) cargo deny, fmt and taplo behaviour in the
merged workspace is unverified: not built. (3) the version placeholder warning of crane for the
virtual root manifest (cosmetic).
Needs from the coordinator (idle host, heavy gates): nix build -L .#checks.x86_64-linux.komorebi-workspace-clippy
(the root deps derivation is a new one because of the lock), .#checks.x86_64-linux.komorebi-workspace-deny,
-fmt, -nextest, -toml-fmt; the same for kfde-komorebi-workspace-{clippy,deny,fmt,nextest,toml-fmt,doc},
kfde-schema-fresh, .#packages.x86_64-linux.kfde-komorebic and kfde-komorebi; then one KDE VM fast run
(the KDE package derivation changed); on a Mac or a darwin builder: .#packages.aarch64-darwin.kfm-komorebic,
kfm-komorebi, kfm-komorebi-bar and the kfm checks. Not run by me: any of these.
komorebi-for-kde/*, komorebi-for-mac/* crates become members of the root Cargo workspace: one
Cargo.lock (901 packages; the 859 Windows entries are unchanged, checked by name and version), the
two nested [workspace] manifests and lock files are deleted, their inherited dependencies are written
out per crate (script S/pkg-merge.py), KDE's .cargo/config.toml (COMMIT_HASH default) moves to the
root .cargo/config.toml (non-forcing, nix still wins). default-members is the Windows set, so a bare
cargo command (and crane, which passes no --workspace) builds only Windows crates; the KDE and macOS
crates are selected with -p. Crates only KDE used were re-resolved newer by cargo; pinned back to the
KDE lock (zbus, zbus_macros 6.1.0, zbus_utils 6.0.0, zruntime 0.2.1, sysinfo 0.40.0). Two small
differences remain: unicode-width 0.2.2 (KDE locked 0.2.3) and libz-sys 1.1.31 (macOS locked 1.1.30).
The root flake and the two nested flakes still read the old workspaces and do not evaluate at this
revision: they are fixed in the next one, which must land with this one (nix cannot be half-merged).
Not behaviour.
Gates run: Windows clippy --all-targets -D warnings (default-members) PASS; KDE check + 294 lib + 5
schemas PASS from the root workspace; macOS fake-CC check of the four macOS packages --locked PASS.
Not run: nix (broken until the next revision), VM, e2e. tools/fast-check now detects the merged
layout.
The package name komorebi is needed for the single komorebi binary package (Option A of
docs/dev/unified-binaries.md). The daemon library becomes komorebi-windows with [lib] name and
[[bin]] name unchanged (komorebi); komorebi-client uses package = ...; the version lookup in the
justfile and cargo wix -p in the release workflow follow. Cargo.lock only renames one entry (checked).
Not behaviour: same sources, same binary name.
Gates run: fast-check --since base: Windows clippy PASS, KDE and macOS PASS, nix eval PASS.
tools/e2e-needed lists the e2e binaries as affected (the closure crate's manifest changed), so the
Windows e2e gate is OWED by the coordinator; the produced komorebi.exe should be unchanged code. Not
run: nix builds, e2e.
The three trees are going to share one Cargo workspace, where package names must be unique. The
KDE packages become komorebi-linux, komorebic-linux, komorebi-client-linux and version-linux, the
macOS ones komorebi-macos, komorebic-macos, komorebi-client-macos, komorebi-bar-macos and
version-macos. Library and binary names do not change ([lib] name, [[bin]] name; dependents use
package = ...), so no source line changes and the binaries are still komorebi, komorebic and
komorebi-bar. Both Cargo.lock files only rename entries (checked: same name/version set otherwise).
The justfiles and the KDE flake (cargoExtraArgs) that name a package are updated here. Not behaviour.
Gates run: fast-check --since base: Windows clippy PASS, KDE check + 294 lib + 5 schemas PASS, macOS
fake-CC check --locked PASS, nix eval of both flakes PASS; KDE cargo test --workspace 879 passed 0
failed (tests/version.rs included); tools/kde-closure-check ok; CLI docs oracle byte-identical for
windows, macos and kde (S/step4/oracle-check.sh, now path-independent and name-aware). Not run: nix
builds, VM suites, e2e. Needed from the coordinator: nothing for the Windows daemon (not renamed
here); the KDE package derivations change name, so one KDE build/VM run will rebuild.
clap derives the command name from CARGO_PKG_NAME. The packages are about to be renamed
(komorebi-windows, komorebi-linux, komorebi-macos, komorebi-bar-macos) while the binaries keep
their names, so the name is written in #[clap(name = ...)] on the three daemons and the two bars.
komorebic already names itself in komorebic-core. Not behaviour: the names are the ones the
packages give now. Verified: KDE tests/version.rs is the test that reads the name (run in the
next revisions); fast-check below. Not verified: macOS and Windows runs.
wip-u-nix narrowed the KDE source to the crates in the KDE cargo closure; the settings stack
(wip-stage) adds crates/komorebi-settings to that closure, so tools/kde-closure-check failed on the
merge of the two. Not behaviour. Verified: tools/kde-closure-check passes. Not verified: nix build.
The Windows and macOS komorebic embed applications.json with include_str!, and build.rs
downloaded it when missing (the files were git-ignored). A build script that needs reqwest, and
so openssl on Linux, cannot be part of one package that also builds there, and the download
made nix builds depend on a copy step. The two files are now committed, byte-identical to the
asc flake input (applications.json and applications.mac.json, checked with cmp); the Windows
build.rs keeps only shadow-rs; the macOS build.rs is gone. The flake preBuild copy of the input
file stays and is now a no-op. Not behaviour: same embedded bytes.
Verified: fast-check --since base: Windows clippy PASS, macOS fake-CC check PASS (--locked, so
Cargo.lock unchanged). Not verified: nix builds.
Merge of wip-stage (kfde, bar, settings), wip-cand1 (kfw, kfm), wip-u-nix and wip-u-pkg (the
unified-binaries doc), so the migration is built on the open stacks and does not conflict with them later.
Records the spike (revisions on wip-u-pkg-spike, nothing landed on wip-main): one root
workspace holds the Windows, KDE and macOS crates with one Cargo.lock (+41 packages), the
unified komorebic builds on all three targets, KDE tests pass unchanged except one test
that reads the package name. Recommends komorebic and bar as one crate with cfg(target_os)
modules and the daemon as three gated libraries behind one thin binary, lists the migration
order, risks, gates (compile, S oracle, nix, e2e, KDE VM, Mac hand check) and the file moves
that conflict with the open wip-u-* stacks.
Verified: Windows cargo check -p komorebic, KDE check and 879 of 880 tests, macOS fake-CC
check, all on the spike tree. Not verified: nix builds, e2e, VM, any macOS link or run.
Staging merge of three stacks that make no runtime change on Windows or KDE: the KDE Backend/Container/process_command refactors (wip-u-kfde), the shared bar core moves (wip-u-bar) and komorebi-settings with the S1/S2 pins (wip-u-settings). Conflicts, if any, are resolved here. Not yet gated: the KDE VM suites and the Windows bar check are owed.
New module settings.rs: MacosSettings (empty platform part) and settings(),
a LazyLock<Handle<MacosSettings>> starting from Shared::defaults_for(
PlatformDefaults::MACOS). Nothing reads it yet, so nothing changes at
runtime. A test pins that the starting settings equal the starting values of
the statics (as for KDE); it is type-checked only, because macOS tests
cannot run on this host. Plan step 10, S2. Pure refactor.
Verified: macOS fake-CC cargo check --locked --target aarch64-apple-darwin
--workspace --all-targets: 0 errors. The pin test was not run (no Mac).
DEFAULT_RESIZE_DELTA, DEFAULT_MOUSE_FOLLOWS_FOCUS and the initial values of
DEFAULT_WORKSPACE_PADDING and DEFAULT_CONTAINER_PADDING now come from
komorebi_settings::shared (PlatformDefaults::MACOS); the statics keep their
names and types, so no reader changes. Adds the komorebi-settings path
dependency (Cargo.lock +1 package). Plan step 10, S1. Pure refactor: same
values (50, true, 5, 5). BORDER_OFFSET_ADJUSTMENT stays where it is: it is a
macOS-only constant (the platform part, later).
Verified: macOS fake-CC cargo check --target aarch64-apple-darwin
--workspace --all-targets: 0 errors (type-check only; nothing linked or run;
no Mac).
New module settings.rs: KdeSettings (empty platform part) and settings(), a
LazyLock<Handle<KdeSettings>> starting from Shared::defaults_for(
PlatformDefaults::KDE). Nothing reads it yet, so nothing changes at runtime.
A test pins that the starting settings equal the starting values of the
statics (paddings, resize delta, mouse follows focus, border enabled/width/
offset/radius and the six colours), so that S3 and S6 can move each group
over without changing a default. Plan step 10, S2. Pure refactor.
Verified: KDE cargo test -p komorebi --lib --tests (lite env, own target
dir): all test binaries ok, 0 failed, including the new pin. KDE VM suites
not run.
DEFAULT_RESIZE_DELTA, DEFAULT_MOUSE_FOLLOWS_FOCUS and the initial values of
DEFAULT_WORKSPACE_PADDING and DEFAULT_CONTAINER_PADDING now come from
komorebi_settings::shared (PlatformDefaults::KDE); the statics keep their
names and types, so no reader changes. Adds the komorebi-settings path
dependency (workspace and package manifest, Cargo.lock +1 package).
Plan step 10, S1 (docs/dev/settings.md section 5). Pure refactor: same
values (50, true, 5, 5), pinned by the crate's platform-defaults test.
Verified: KDE cargo test -p komorebi --lib --tests (lite env, own target
dir): all test binaries ok, 0 failed. KDE VM suites not run.
Shared now holds every non-platform setting of docs/dev/settings.md 2.1:
border (enabled, width, offset, radius, six colours), animation (global and
per-prefix enabled, style, duration; fps; Animation::motion_for reading all
three from one snapshot), paddings and constants, transparency, floating
window aspect ratio, layout defaults, display index preferences, with the
per-platform defaults (PlatformDefaults::{WINDOWS, KDE, MACOS}: border 8/10/10
and -1/0/0, padding 10/5/5). SharedDelta::apply reproduces what
StaticConfig::apply_globals does with each key: absent keys keep the old value
(border, paddings, transparency, display preferences, a missing animation
block), absent layout_defaults and floating_window_aspect_ratio reset (the
latter to Standard although the static starts at Widescreen), an animation
block without fps resets fps, a global animation value clears its per-prefix
map and a map replaces the whole map.
No daemon uses the crate yet.
Verified: native cargo test -p komorebi-settings: 18 passed (9 handle, 9
shared: defaults per platform, default colours equal the komorebi-themes
conversion, keep-versus-reset per key, animation merge, motion_for);
clippy clean for the crate. The tests encode what apply_globals does as read
on wip-main; they were not run against the daemons.
New crate crates/komorebi-settings (workspace member, Cargo.lock +1
package, no new third-party dependency). Settings<P> is a shared part and a
platform part P; Handle<P> holds the current value as an Arc that readers
snapshot once per unit of work and writers replace through update (writers
serialised, one publish, nothing published if the edit panics). Handle::scoped
sets one field and restores the previous value on drop only if the field
still holds the value it set, replacing the save-and-restore store pairs in
the daemons (Windows WINDOW_HANDLING_BEHAVIOUR, KDE ANIMATION_ENABLED_GLOBAL).
Shared starts with the border and the per-platform defaults; the rest follows
in the next revision. See docs/dev/settings.md.
No daemon uses the crate yet.
Verified: native cargo test -p komorebi-settings: 9 passed (snapshot
isolation, concurrent updates lose nothing, no torn reads under a writer,
scoped restore and 'change made meanwhile wins'); clippy clean for the crate.
komorebi-config warns about an unused import when built without its schemars
feature (not touched here). KDE, macOS and Windows trees not touched.
Measured on wip-main 633e7453 by grep and reading: 126 (Windows), 53 (KDE)
and 74 (macOS) static declarations, of which 61/35/36 are configuration and
51/29/28 are written by apply_globals. The document has the per-static
table (type, writers, readers, shared or platform, matching name), the lock
order of the rule lists, the proposed Settings (shared part plus a platform
type parameter, snapshot reads, serialised updates, scoped override), the
statics whose semantics would change (reload merges rather than replaces;
partial updates visible mid-reload; save-and-restore writes; the empty
WORKSPACE_MATCHING_RULES window), the migration order with pure refactor
versus BEHAVIOUR marks and the gate each needs, and section 7 with the
findings from encoding the semantics in the crate (aspect ratio starts at
Widescreen but a load without the key writes Standard).
Verified: nothing run (documentation); counts from grep, line numbers read
at 633e7453.
The KDE source filter took all of crates/, so an edit of
crates/komorebi-bar-core, which KDE does not depend on, changed every KDE
check and VM suite derivation. The filter now takes the nine crates of the
root workspace in the KDE cargo closure, listed in
komorebi-for-kde/nix/root-crates.json (read by the flake and by
tools/kde-closure-check, which fails if the list differs from
`cargo metadata` of the KDE workspace; a new dependency is therefore a
check failure, not a silent skip). The crates/ directory itself still passes
the filter so that its listed members are reached.
Safety: komorebi-gui, komorebi-bar and the e2e crates are already absent
from the KDE source while the root manifest lists them as members, so a
missing member directory is already tolerated. Not proven by a build.
Verified (nix eval of drvPath in a throwaway git copy, 7 commits): an edit
of crates/komorebi-bar-core leaves kfde clippy, nextest, the packages and
kfde-vm.stacks and .commands unchanged (before: all changed); an edit of
crates/komorebi-config changes them; the kfde package still evaluates.
tools/kde-closure-check passes, and fails when a crate is removed from the
list.
komorebiVm (the python package every KDE VM suite imports) took all of lib/,
including lib/tests. The VM never runs those tests and setuptools does not
package them, but editing one changed komorebiVm and so rebuilt every suite
(34 of 34, about 50 min of the fast tier). It now takes lib/ minus lib/tests.
libCheck (vm-lib) keeps its own source, so the unit tests still run.
Verified (nix eval of drvPath in a throwaway git copy): an edit of
lib/tests/test_keys.py leaves kfde-vm.stacks and kfde-vm.commands unchanged
(before: both changed). Not verified by a build.
COMMIT_HASH was in commonArgs, so buildDepsOnly (about 1000 dependencies)
and every check (clippy, nextest, fmt, deny) got a new derivation for every
commit, even a docs-only one, and rebuilt in full.
commonArgs now carries the constant "nix-check" (as the KDE flake already
does) and only fullBuild, and so packages.default and the extracted
binaries, gets the real commit. The e2e build keeps its own constant through
the existing `commit` argument. Nothing the checks compile or test changes;
only the string shadow_rs stamps into the check binaries.
Verified (nix eval of drvPath in a throwaway git copy, 7 commits): the deps
derivation is identical for a docs edit, a Windows source edit, another docs
edit, a bar-core edit and a KDE-crate edit; clippy, nextest and fmt are
unchanged by the docs edit and change only for source edits;
packages.default changes with every commit (real commit embedded). Not
verified by a build: needs one idle-host nix build (commands in
tools/README.md).
docs/dev/core-model.md: per-file measured differences between the
Windows, KDE and macOS container, monitor, workspace, window and
window_manager (stripped code lines, changed lines, identical lines),
the platform-specific fields and methods of each layer, a proposed
split into a komorebi-core crate generic over a Platform (Backend plus a
Copy-or-Clone Window and a state type) with the exact order of layers
(container, monitor, workspace, window_manager, router), what the KDE
stack of wip-u-kfde already did, what Windows must do before the crate
can be created, and the list of KDE process_command arms over 20 lines
with the method each became. Measurements are from diff of the files at
this tip; nothing was run on Windows or macOS.
Verified: not applicable (documentation); the numbers were produced by
diff and wc on the files at wip-u-kfde.
Plan step 9 prerequisite, last cluster of process_command: Query (51
lines) becomes answer_query(query, reply), ReplaceConfiguration (34)
becomes replace_configuration(config), BorderColour (21) becomes
set_border_colour(kind, r, g, b). After this no arm of KDE's
process_command is longer than 20 lines (the only longer one is the
list of not-supported messages, which has no logic). Bodies are the
arms' bodies, dedented. No behaviour change.
Verified: KDE cargo test -p komorebi --lib --tests (native, FakeBackend):
633 passed, 0 failed. Not run: doc tests, VM suites.
LGUG2Z