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.
docs/dev/core-model.md section 19: remove_floating_window's hook is
before_floating_removed (behaviour unchanged), and the Windows title-bar
tables are taken once per pass through begin_pass; the sentence of
section 16 that called the per-container read an improvement is
corrected.
Verified: not applicable (documentation).
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
LGUG2Z