One page with the exact commands for each platform, so nobody has to
reconstruct them from the flakes and the progress notes:
- Windows: nix cross build of the binaries, the crane checks (clippy is the
pre-landing gate), the e2e-tests check, native tests of the neutral crates;
- KDE: cargo check/test with the right package names (the unit tests are in
komorebi-linux, not the thin komorebi binary package), the schema test with
one thread, the kfde-* checks of the root flake, the VM suites with `just vm`,
the tier lists, E2E_ONLY and KOMOREBI_RECORDER for VM runs;
- macOS: cargo build/test/clippy with `-p komorebic -p komorebi -p komorebi-bar`,
never `-p komorebic-macos` together with `-p komorebic`, and the Linux-only
type-check;
- Windows e2e: `nix run .#e2e-windows`, the `bar` scenario, E2E_ONLY, trace,
recorder, KEEP_GUEST, SCALE, STATE, bins from another commit;
- a what-to-run table and the known flakes with counts, summarised from the
flake registry kept by the gate runs (no personal paths).
It also records that komorebi-for-kde/justfile still assumes a KDE-only
workspace (`just check` would build the Windows crates).
Verified by running: `cargo metadata --no-deps` (package names), `cargo check
-p komorebi-linux -p komorebi -p komorebic` in komorebi-for-kde (ok), `nix eval
--json .#legacyPackages.x86_64-linux.vmTiers` (the tier lists match). Other
commands were read from flake.nix, justfiles and the e2e README, not run.
A new reader had no single page that said where things are: three platform
trees, nine shared crates, the four unified packages, the shims that remain,
and which differences are on purpose. The page gives:
- the three trees and what lives in each (root = Windows, komorebi-for-kde,
komorebi-for-mac) and that the root Cargo.toml is the only workspace;
- the packages komorebi (komorebi-daemon, cfg_select! over komorebi-windows,
komorebi-linux, komorebi-macos), komorebic, komorebi-client, komorebi-bar
and their cfg(target_os) layout, and the shim packages until the cutover;
- the crates/ map (protocol, config, collections, transport, backend, core,
settings, bar-core, komorebic-core);
- where the platforms differ on purpose, with a pointer to seam.md,
core-model.md, settings.md, unified-binaries.md, bar-unification.md and
macos-handcheck.md;
- the oracles (wire goldens, config and bar schemas, CLI docs, derivation
drift) and the tiered feedback loops;
- the tools outside the repository (fast-check, mac-check.sh,
kde-closure-check, e2e-needed, gate-lock, ...) with a proposal of which to
commit; nothing was moved.
Statements were checked against Cargo manifests (cargo metadata --no-deps
lists the package names used), flake.nix and the source directories. The
version numbers and the packages list were read from manifests. Not built;
macOS statements are what the progress log says, not observed.
The documents in docs/dev were written at different points of the
consolidation and some of their statements are history (for example
unified-binaries.md still says "never write -p komorebi", true before step 8).
Each now opens with a "Status (wip-cand4)" line saying whether it is design,
evidence or a log, what has landed, what has not, and, for
unified-binaries.md, which part is superseded.
The statuses were taken from the revision list wip-main..wip-cand4 and the
progress log, not from re-measuring. Only the line under the title was added;
no existing text changed. Not built.
Candidate 4: wip-cand3c (core line with macOS on komorebi-core, HideSpot, settings S1-S3, bar e2e scenario, handover scenario fix), wip-u-core3 (shared Workspace update_shared and the Windows converge of window_manager/process_command), wip-u-stallfix (lock-holder instrumentation, sysinfo scan before the lock, bar restart and hwnd file off the lock, subscriber write timeout) and wip-u-pkg2 (one komorebi package and binary, daemons as libraries). Conflicts, if any, are resolved here.
docs/dev/core-model.md section 18: the shared share of window_manager.rs
after the converge (26% identical with Windows, 37% within four lines,
63% differing or one-sided, so not above the 60% bar), a table of the
near-identical functions and why each is cosmetic or real (the Windows
handle_unmanaged_window_behaviour calls in 18 functions against the router
call on KDE and macOS, borders, floating windows in monocle, workspace
names, custom layouts, id types), the 25 differing router arms (two
converged, the rest real; FocusWorkspaceNumber(s) and FocusLastWorkspace
probably an omission on KDE), and the seven blockers.
Verified: not applicable (documentation); numbers from the function
comparison at this tip.
New extras scenario e2e/platforms/qemu_windows/extras/bar.py, registered in
run.py as `bar` (runs after the tiling windows, like the other Windows
extras). It starts komorebi-bar in the guest with a configuration that has
storage, time, applications, komorebi workspaces and layout widgets, the
Windows-only Keyboard and Systray widgets and a `mouse` block (a message and
a command), and checks: `komorebi-bar --schema` equals the checked-in
schema.bar.json byte for byte; the process starts and its window titled
komorebi-bar appears, visible and sized; it runs 15 s (scaled); `komorebic
state` answers and komorebi does not tile the bar; commands that notify the
bar work; the bar survives `komorebic stop` and the daemon starting again as
the same process (it reconnects: it does NOT exit when the daemon stops, so
the task text "exits cleanly when komorebi stops" is checked as
`komorebic stop --bar` ending daemon and bar); screenshots are kept as
artefacts, no pixel assertions. No known failures.
Plumbing: run.py uploads komorebi-bar.exe when the binaries directory has it
(other scenarios do not need it, so older build-ref directories still work),
the nix app copies it and sets KOMOREBI_E2E_BAR_SCHEMA to the checked-in
schema (the e2e directory alone does not contain it), build-ref.sh builds it.
README and docs/dev/bar-e2e.md document it.
Verified: py_compile and ruff clean; the runner and library unit tests: 157
passed; flake.nix parses. NOT run: the scenario itself (the Windows guest is
reserved for gates), so every check is untested against a real bar and may
need adjusting (window title, timings, the Systray widget inside the VM).
Needs gate: win-e2e `bar`.
docs/dev/core-model.md section 16: update_shared and where it departs from
section 12, and what macOS's update keeps (SkyLight batch, no maximized
branch, a separate scrolling path, an unconditional clamp, no stackbar) as
three decisions for its owner. Section 17: process_command arm by arm (110
of 155 arms in all three daemons identical, 45 not, with the clusters of
the differing ones), process_event (only three of the events exist on all
three, so it is the thin-events step), and window_manager function by
function (39 identical in all three, 48 differing, the one-sided lists,
the 20 functions that are identical in KDE and macOS and old only in
Windows), with the order and the hooks of the remaining layers of step 9.
Verified: not applicable (documentation); the counts come from the arm and
function comparison of the three trees at this tip.
Merge of kfm's macOS core migration (wip-u-kfm2 9cb4f2fa) and the settings
stack through S3 (wip-u-settings2 696d2929), both on wip-u-integ2. Two files
conflicted, both macOS; every hunk is resolved the same way: take kfm's
version of the file (its new shapes: komorebi_core Monitor/Workspace,
workspace_config and monitor_config as free functions) and re-apply the S3
change to it, because the settings side only touched lines kfm moved.
- komorebi-for-mac/komorebi/src/monitor.rs: conflict 1 (imports): kfm's
header doc kept, the DEFAULT_CONTAINER_PADDING / DEFAULT_WORKSPACE_PADDING
imports dropped (S3). Conflict 2 (std imports): kfm's side (no VecDeque).
The four padding reads (the two default fallbacks in the monitor's
workspace globals) call crate::settings::container_padding() /
workspace_padding(); the now unused Ordering import is removed.
- komorebi-for-mac/komorebi/src/static_config.rs: both conflicts are the
padding defaults in kfm's free functions (workspace_config, monitor_config):
kfm's text kept, the two defaults read from settings. Re-applied S3 in this
file: apply_globals applies paddings, aspect ratio, layout_defaults and
display_index_preferences as one Handle::update of a SharedDelta; the
readers (layout_defaults, aspect ratio, display preferences, paddings) use
the accessors; the statics' imports and the now unused AspectRatio imports
are removed.
komorebi-core and the shared crates read none of the removed statics
(grep: only the unrelated DEFAULT_*_PADDING consts in komorebi-config), so no
hook is needed. S3 semantics are unchanged from wip-u-settings2 (statics
removed, one update per load, reload merges, a few keys reset); the pins
are the settings crate's reload.rs and shared tests plus the KDE
tests/config.rs.
Verified: see the run in the progress log (macOS fake-CC clippy -D warnings
-p komorebi-macos --all-targets clean at this revision).
Records the HideSpot change and the three macOS layers (container, workspace,
monitor) as done, lists the functions that stay in the macOS extension traits,
and notes that ContainerExt is the old container code kept for the daemon's own
call sites.
Verified: documentation only.
Section 9 of docs/dev/settings.md: what S3 moved, how apply_globals and the
command write it, how readers get it, and that the only BEHAVIOUR is the
single publish.
Verified: not applicable (documentation).
Step 11(iii), the Monitor layer. BEHAVIOUR (type-checked and clippy-clean with the
fake CC; the macOS tests are the oracle and have not run).
pub type Monitor = komorebi_core::Monitor<MacosPlatform>. MacosPlatform
implements MonitorPlatform: the id is the u32 display id written as a number, the
serial number a String, and the extra fields MacosMonitorExtra {
window_hiding_position}, flattened into the monitor's JSON (the key was already
the last of the macOS monitor, so the text is the same; a test pins the keys and
their order). The shared monitor gives focus_workspace, add_container,
remove_workspace_by_idx, remove_workspaces, ensure_workspace_count,
new_workspace_idx and the two name/layout lookups (nine functions that were the
same text or differed only in their types). The rest stays macOS's as
MonitorExt: new, placeholder, update_focused_workspace, update_workspace_globals,
update_workspaces_globals, update_all_workspace_globals, load_focused_workspace,
hide_unfocused_workspaces, restore_focused_workspace, move_container_to_workspace
(and its '1' variant) and add_container_with_direction, because they differ from
the KDE ones in what they do (SkyLight batches, the corner, the animator). The
monitor writes its corner into each workspace's state when it updates the
globals. From<&Monitor> for MonitorConfig, an orphan impl now, is the function
monitor_config. Monitor::new and Monitor::placeholder are called through the
MonitorExt trait.
No silent bind: no MonitorExt method shares a name with a method of the shared
monitor (checked: empty intersection); the shared and the old text differ only
in types, and a call of an old signature does not compile.
Verified: fake-CC cargo clippy --locked --target aarch64-apple-darwin -p
komorebi-macos --all-targets -D warnings clean; tools/fast-check macOS PASS.
Not verified: any macOS test or run. Verified on the Mini: not yet. Gate: the
Mini's cargo test, then the hand check row in docs/dev/macos-handcheck.md.
Step 11(iii), the Workspace layer. BEHAVIOUR (type-checked and clippy-clean with
the fake CC; the macOS tests are the oracle and have not run).
pub type Workspace = komorebi_core::Workspace<MacosPlatform>. About 53 of the
65 functions of the macOS workspace.rs are the shared ones now (identical, or
differing only in the id type, the Container type or a hook; section 14 of
core-model.md lists them). MacosPlatform implements WorkspacePlatform:
foreground_window_id and cursor_position (the same MacosApi calls),
should_act_window(_individual) (the macOS should_act with the class as a
one-element slice), the three scrolling hooks, after_floating_removed
(focus_previous_floating_window, which is shared), and the two hide spots:
hide_spot is the monitor's corner with no display (what every Window::hide
call had), hide_spot_on_display adds the display bounds from the work area
(what Workspace::hide gave the containers). The corner is MacosWorkspaceState,
which the monitor sets next to the globals (it was a field of the macOS
WorkspaceGlobals, which is now the shared type; both are serde-skipped, so
the JSON is the same). The eight functions that took the hiding position
(hide, move_window_to_container, new_floating_window,
new_container_for_focused_window, new_container_for_window,
reintegrate_monocle_container, new_monocle_container, focus_container_by_window)
are the shared ones with the spot argument; the ones that stay macOS's are
WorkspaceExt (update, apply_wallpaper, restore, remove_window,
load_static_config, prune_duplicate_windows, visible_window_details,
reap_invalid_windows_for_application, restore_windows, calculate_layouts,
set_scrolling_columns) and, in scrolling.rs, the former inherent methods now
the trait WorkspaceScrolling (an inherent impl on a type of another crate is not
allowed). The Window implements WorkspaceWindow (class is its role, path a
String). From<&Workspace> for WorkspaceConfig, an orphan impl now, is the
function workspace_config. The shared Workspace has one field macOS lacked
(initial_window_placement_rules, None and skipped when None), so the JSON
has the same keys: new test state_pin pins them.
Behaviour that is deliberately kept: floating windows are hidden at the corner
with no display (hide_spot), containers with the display; ContainerWindow's
hide and restore skip their work under cfg!(test), as the old container code did.
No silent bind: the names of the methods of WorkspaceExt, WorkspaceScrolling
and ContainerExt share no name with a method of the shared Workspace
(checked mechanically: the intersection with the core inherent names is only
Container::restore, a different type); and each of the shared functions that
used to take the corner has a different signature from the macOS one it
replaced, so a stale call is a compile error, which was the order in which the
errors showed up.
Verified: fake-CC cargo clippy --locked --target aarch64-apple-darwin -p
komorebi-macos --all-targets -D warnings clean; tools/fast-check macOS PASS.
Not verified: any macOS test or run. Verified on the Mini: not yet. Gate: the
Mini's cargo test, then the hand check added to docs/dev/macos-handcheck.md.
Records the result of the Container move and why Workspace<MacosPlatform> is
not started: eight shared workspace functions call the no-argument infallible
hide forms while macOS passes the monitor's corner and display and
propagates the error; four of them have the same signature as macOS's own, so
the switch would bind the shared body silently (a behaviour change that the
type-check cannot see). Proposes the core change (an associated HideSpot type
on ContainerWindow, () on KDE and Windows, taken from the workspace
globals, and a fallible result) and lists the small mismatches that also
come first (path as String, class, should_act's class slice, the scrolling
hooks).
Verified: documentation only.
Step 11(iii), the Container layer. BEHAVIOUR (type-checked and unit-test
oracle only; macOS cannot run here).
pub type Container = komorebi_core::Container<Window>, with ContainerWindow
implemented for the macOS Window (id is the CGWindowID, exe_name its exe;
hide_window and restore_window use the default corner and log a failure,
because the daemon does not hide through them). The container's own struct,
accessors, preselect, idx_from_exe, contains_window, idx_for_window,
remove_window_by_idx, remove_focused_window and focus_window are now the
shared ones. The four functions that carry the monitor's WindowHidingPosition
(and for hide the display bounds), return a Result and skip the work under
cfg!(test) stay macOS's own, as ContainerExt, under names the shared type
does not use: add_window_at, load_focused_window_at, hide_on and
restore_focused_window (an inherent method of the shared type would shadow an
extension method of the same name); about 35 call sites follow. The shared
Container reads a missing 'locked' as false (macOS used to require it).
komorebi-core is a dependency of the macOS daemon (and its schemars feature).
State JSON: two new tests pin the shape ({id, locked, windows: {elements,
focused}}) and the missing-locked read; the existing round-trip test is kept.
They can only run on a Mac.
Verified: fake-CC type-check (tools/fast-check) PASS on all targets; Windows
clippy, KDE check and tests unaffected PASS. Not verified: any run. Verified
on the Mini: not yet. Gate: the Mini's cargo test; then the hand check added to
docs/dev/macos-handcheck.md (stacks, workspaces, state JSON, per-monitor
hiding corner).
Merge of wip-u-core (kfde: komorebi-core with Container, Workspace<P>, Monitor<P>) and wip-u-pkg-mig3.
Conflicts and how they were resolved:
- komorebi-for-kde/Cargo.toml, komorebi-for-kde/Cargo.lock: deleted, as in the migration (one root
workspace); kfde's only edit there, the komorebi-core workspace dependency, is applied as a path
dependency in the crate manifest.
- komorebi-for-kde/komorebi/Cargo.toml: the migration's manifest (inlined dependencies, package name
komorebi-linux, [lib]/[[bin]]) plus kfde's komorebi-core dependency and the komorebi-core/schemars
feature.
- Cargo.lock: the migration's lock re-resolved with cargo metadata --offline: the only change is the
new komorebi-core 0.1.42 entry; no version of any other package moved (compared by name/version with
both parents; kfde's Windows lock differs only by the komorebi -> komorebi-windows rename).
- komorebi-bar/src/widgets/komorebi.rs: deleted (the Windows bar moved to komorebi-bar/src/windows/);
kfde's one-line edit (title: value.title() instead of value.title().ok()) applied to
komorebi-bar/src/windows/widgets/komorebi.rs.
- komorebi-for-kde/nix/root-crates.json: crates/komorebi-core added (tools/kde-closure-check now ok with
11 root crates).
Gates run: tools/fast-check --since wip-u-pkg-mig3: native tests, Windows clippy -D warnings, KDE check+lib+schemas, macOS fake-CC check, nix evaluation (root and both nested flakes) PASS; KDE cargo test -p komorebi-linux -p komorebic -p komorebi-client -p komorebi-hotkeys -p komorebi-core: 902 passed, 0 failed; CLI docs oracle identical x3; bar schema harness byte-identical for both bars (its Window::title stub now returns Option); bar-core tests 3+6; kde-closure-check ok; by evaluation an edit of the Windows bar or daemon leaves the kfde derivations unchanged, a KDE edit leaves Windows unchanged, and an edit of crates/komorebi-core changes Windows and kfde but not macOS. Not run: nix builds, VM, e2e (the Windows daemon changed: kfde's e2e gate applies), any Mac run.
Classifies every function of komorebi-for-mac/komorebi/src/{container,
workspace,monitor}.rs against komorebi-core (or the KDE extension traits):
container 5 identical, 6 text-only, 4 real (the hiding functions); workspace
11 identical, 26 text-only, 8 differing only through hooks that exist, 8
differing by the hiding position, 4 real, 3 text in the extension trait, 5
macOS-only; monitor 5 identical, 4 text-only, 8 in the extension trait, 4
macOS-only. States the one difference that decides the order: the hiding
position and the fallible hide.
Verified: counts from a function-by-function diff run on this host (stripped
text, namesake against namesake); documentation only. Not verified: that the
text-only functions behave identically on a Mac, which the macOS tests will
show once they run on the shared code.
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.
docs/dev/core-model.md section 13: what Monitor<P> holds and what stays in
MonitorExt, why the two globals updates are not shared (KDE's plural one
has no border), the serde facts the tests pin (flattened map keys, the
schema order) and the hooks of promote_container, effective_layout_options,
new_floating_window and hide.
Verified: not applicable (documentation).
docs/dev/core-model.md section 12: the skeleton of Workspace::update that
can move into komorebi-core (begin_update with the Flow guard,
containers_pruned, place_monocle, maximize_in_layout,
adopt_widths_before_layout for the scrolling-in-motion condition,
monitor_rects, adjust_layout per container, place_container, end_update
returning Pass), a table of the body each daemon keeps in each hook, the
constraints that make it safe, and the unified diff of the two update
bodies at this tip as the exact record. Not implemented: it waits for the
Windows e2e gate.
Verified: not applicable (documentation).
docs/dev/core-model.md section 11: Workspace<P> and its shared functions
are in komorebi-core and both daemons use it; the functions left in the
extension traits (remove_window, restore, new_maximized_window,
reintegrate_maximized_window, apply_wallpaper, update, the custom
layout arms) differ in what they do and not only in how they are
written, listed one by one with the difference; hide and
new_floating_window can be shared once their hooks exist. Where Monitor
stands.
Verified: not applicable (documentation).
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.
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.
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.
docs/dev/core-model.md section 10: 58 functions (about 530 lines) are now
identical on both sides, only new_container_for_window depends on a
differing function (resolve_placement_index), and a table of every
remaining difference with the converge step or hook that removes it, plus
what ContainerWindow must grow before the first generic function
compiles.
Verified: not applicable (documentation).
docs/dev/core-model.md section 9: three corrections to section 8 found by
reading KDE's workspace.rs next to the Windows one (begin_update must be
fallible and mutating because KDE prunes duplicates and clamps the focus
first; end_update must return Pass::Again because Windows' update loops
for scrolling; a scrolling_in_motion condition is read mid-update on both
platforms; adjust_layout is per container for the stackbar), the error
policy of place_window, the orphan-rule cost of extension traits, that
WorkspaceConfig is already shared, that Monitor cannot move before
Workspace (it uses about 25 of its members), the visible-windows decision
for the owner, and the order of what remains.
Verified: not applicable (documentation).
Design only, no code. Section 8 of docs/dev/core-model.md: Workspace<P:
WorkspacePlatform> with defaulted hooks for the six (c) differences of
section 7 (begin_update / adjust_layout / place_window / end_update,
apply_wallpaper, on_window_removed, after_hide, unmaximize_window), what each
platform does in them, the statement that Windows needs no unmaximize in
reintegrate_maximized_window or new_floating_window, how the (d) features
become extension traits or associated state (border_kinds_on_show,
windows_on_show, hwnd_from_exe, custom layouts, the KDE-only reaping and
pruning, scrolling_placed, the Windows-only Monitor fields), what has to
exist first, and the order and e2e gates of the implementation.
Docs only.
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.
docs/dev/core-model.md section 7: the two files compared function by
function (not by one whole-file diff, which misaligns): 36 non-test
functions of workspace.rs are identical, the differing ones are 1
cosmetic, 15 same-behaviour-different-text, 6 platform differences and 14
one-sided features, with changed-line counts; monitor.rs likewise (8
identical, 2 b, 3 platform, 9 one-sided). Lists what each remaining
cluster needs, as the hand-over to the Windows side.
Verified: not applicable (documentation); the counts come from per-function
diffs of the files at this tip.
docs/dev/core-model.md section 6: what komorebi-core holds (Container<W>,
ContainerWindow), how KDE and Windows use it, how the JSON is pinned, and
why Monitor is not moved yet: after kfw's convergence the two monitor.rs
still differ by 657 changed code lines (extra Windows fields name,
device_id and workspace_names, serial_number_id Option vs String, the
hmonitor_json id, MonitorInformation fields, the workspace show/hide and
globals methods), which is a decision about the state JSON and a Platform
hook design, not a mechanical converge. Lists what remains in order.
Verified: not applicable (documentation); the 657 comes from diff of the
files stripped of comments and blank lines at this tip.
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.
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.
window_manager.rs: three WindowsApi::center_cursor_in_rect calls become
backend().center_cursor_in(..) and WindowsApi::disable_focus_follows_mouse
becomes backend().set_focus_follows_mouse(false); workspace.rs: the
WindowsApi::restore_window that unmaximizes a window becomes
backend().unminimize(..) (the same ShowWindow call, after an IsWindow check).
backend-switch.md now lists every WindowsApi call left in window_manager,
workspace and monitor and why each cannot be switched without changing an
error, a default or a flag (foreground_window, cursor_pos, focus on the
desktop window, position_window flags, start-up enumeration, monitor fields).
BEHAVIOUR: a dead window is skipped by the unminimize. e2e gate needed:
commands, focus_follows_mouse, maximizing, workspaces. Verified: Windows
clippy -D warnings via tools/fast-check PASS; e2e not run.
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.
docs/dev/bar-unification.md is brought up to date: what the core holds now
(4,592 lines, the hooks), what is still per platform with fresh
measurements (komorebi.rs 136 differing lines, network.rs 82, bar.rs 444,
main.rs 92, os.rs 71) and why each stays, the known macOS/Windows
differences kept on purpose (including the accept-and-skip of Windows-only
keys, D-coord-1), the proposed layout of the merged package for the
coordinator (module layout with cfg(target_os), dependencies by target,
schema flag, lock-file folding, nix), the ordered plan and the hand check
list. No code changed. The macOS hand-check section for
docs/dev/macos-handcheck.md (owned by kfm, not in this tree) is in the
scratchpad as bar-handcheck-section.md for the coordinator to append.
Verified: figures from diff on this tree. Gates at this tip: native bar-core
tests 3+6, schema harness macOS and Windows byte-identical, Windows clippy
and macOS fake-CC check clean.
Candidate for the Windows e2e gate: the Windows Backend switches and lock order (wip-u-kfw) with the macOS registry and Window methods (wip-u-kfm). Merge of two independent stacks that both touch crates/komorebi-backend; conflicts, if any, are resolved in this revision.
docs/dev/backend-switch.md now has the table of what is switched (focus,
set_rect with top = false, frame reads, plain hide/restore, minimize,
close, raise, maximize), what is left in the Windows crate on purpose
(top = true set_position, the *_with_border calls, transition and ghost
machinery, set_opacity: border and animation subsystems are platform-owned,
seam.md rule 5), and, for each query not switched (foreground_window,
cursor_pos, monitors, window, monitor_from_point), what the trait would
need so step 9 can decide.
Docs only.
process_command (close and minimize of the foreground window, four raise
calls) and monitor_reconciliator (four minimize calls) now call
backend().close/minimize/raise. WindowsBackend runs Window::close,
minimize and raise unchanged (minimize still leaves komorebi-bar alone).
docs/dev/backend-switch.md now holds the full table of what is switched
and what is left, including why the queries (window_rect,
foreground_window, cursor_pos, monitors) were NOT switched: each would drop
an error that callers use or report, or fabricate a default.
BEHAVIOUR: a dead window is skipped by an IsWindow check first; minimize
results are ignored as before. e2e gate needed: commands, monitor
reconciliation (monitor_reconciliator), lifecycle. Verified: Windows clippy
-D warnings via tools/fast-check PASS; e2e not run.
Switch the 40 Window::focus(mouse_follows)? call sites in process_event,
process_command, workspace, window_manager, focus_manager and the
stackbar click to backend().focus(WindowId::from_hwnd(..), mouse_follows).
WindowsBackend::focus runs Window::focus, so the deferral while a window
slides in, the already-foreground shortcut and the cursor centring are
unchanged. animation/transition.rs:534 stays on Window::focus (it is the
code Window::focus defers to). docs/dev/backend-switch.md records what is
switched.
BEHAVIOUR: a dead window now fails early with Error::WindowGone (before:
the Win32 error from raise_and_focus_window) and a failed focus of a window
that died meanwhile reports WindowGone; every caller uses ? or ignores the
result. e2e gate needed: commands, focus, focus_follows_mouse, stacking,
workspaces, lifecycle. Verified: Windows clippy -D warnings via
tools/fast-check PASS; e2e not run.
docs/dev/bar-unification.md: why config.rs, bar.rs and komorebi.rs are not
moved yet, file by file with the measured difference (differing lines and
hunks), the structural blocker (two Cargo workspaces/lockfiles/flakes, two
komorebi-client crates), the schema views that settle schema.bar.json, the
ordered plan, KDE (no bar exists), the macOS commands that spawn cmd.exe or
explorer.exe and are preserved in os.rs, and what must be checked by hand on
Windows and on a Mac.
Verified: figures from diff on this tree; no code changed. Gates at this
tip: schema harness macOS and Windows byte-identical, native bar-core tests
3+5 passed, Windows clippy and macOS fake-CC check clean.
Adds the three BEHAVIOUR-relevant registry revisions (registration and
forgetting, native-tab sync) with what to look for on a Mac, the mechanical
ones to section B, and a status entry in the bug list saying what of step
11(ii) is done and what is deliberately not (animator lanes, borders,
reaper/live-resize timeouts, the model holding bare ids).
Verified: documentation only.
Lists what must be checked on a Mac once the unified binaries exist: every
macOS revision that changes runtime behaviour (the rule-list lock order,
the shared command listener, pause filter, subscriber push, EventChannel,
SocketMessage, animation prefix, StaticConfig, komorebic launcher, bar-core
hooks and library bumps), the mechanical Step 6/11(i) revisions of this
stack, the walk-through the plan names (focus, move, stack, workspaces,
scrolling, pan, borders, animations, display change, sleep and wake), and
the bugs noticed: the main-queue/WM-lock deadlock of seam.md 3.3, cmd.exe
and explorer.exe in the macOS bar, the update widget's wrong repo, the raw
AX sites that remain outside Window.
Nothing in it was run: macOS cannot be built or tested on this host.
Verified: documentation only.
Appends section 9 to docs/dev/seam.md: for each method of the shared Backend, what WindowsBackend and MacosBackend do and where that differs from what the daemon calls today (windows() and macOS's registry cannot be written faithfully; set_rect on Windows drops the top flag and keeps animation and guards; hide/restore results are ignored on Windows; macOS hide needs a corner and a display; raise on macOS also focuses; macOS monitors() has to be a main-thread-refreshed cache; set_opacity on Windows is the plain write). Concludes that the trait did not have to change and records three proposals (rect as Option, hide's hidden inputs, windows() as start-up operation).
Verified: docs only, not built. Every claim is by reading the code while writing the adapters; what could not be settled by reading is marked 'not verified' in the text.
Adds section 7 (the seven consequences of plan step 7, each with its supporting citations and a status: CONFIRMED, CORRECTED or TARGET; plus three findings the plan did not list: a batch/transaction scope, the workspace methods that exist only on KDE, and error-type differences) and section 8 (everything not confirmed, with how to confirm it on a Mac, a Windows guest or by reading). Verified against the citations of sections 2 to 6 on wip-main aa52fdc4d9e5. Not verified: see section 8.
Adds section 6: event sources per platform and how they reach the window manager (references the step 5 prep entries rather than redoing them) and the evidence for the 'set_rect returns once requested, the frame is observed later' contract: KDE queued commands with an optimistic table write, macOS arrival.rs, settle.rs and animator verification, Windows live_resize settling. Verified against wip-main aa52fdc4d9e5: K/kwin/mod.rs, K/kwin/state.rs, K/window_manager_event_listener.rs, K/backend/mod.rs, M/arrival.rs, M/settle.rs, M/animation/animator.rs, M/window.rs, M/window_manager_event_listener.rs, W/winevent_listener.rs, W/windows_callbacks.rs, W/live_resize.rs. Not verified: any runtime ordering of events.
Adds sections 4 (identity: id types per platform, what acting on a macOS window from a bare id would need, where each tree keeps per-window platform data, HWND width including an observation of 440 distinct HWNDs from the Windows guest logs) and 5 (coordinates: Rect convention, origin and y direction, DPI and scale handling, shadow and frame compensation, and where each conversion lives). Closes two plan items: Windows HWND width and macOS Retina points versus pixels. Verified against wip-main aa52fdc4d9e5: komorebi-layouts/src/rect.rs, W/window.rs, W/windows_api.rs, W/lib.rs, K/kwin/state.rs, K/kwin/bridge.js, M/window.rs, M/application.rs, M/macos_api.rs, M/core_graphics/mod.rs, M/core/rect_ext.rs, M/border_manager/border.rs, M/animation/ghost.rs, M/animation/capture.rs, and ~/e2e-w0 logs read-only for the HWND range. Not verified: HWND width as a Microsoft guarantee, AX values on scaled-resolution or mixed-DPI displays, negative monitor origins on Windows.
LGUG2Z