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