"there is no maximized restore index" and "there is no maximized window"
replace the two strings that were copied from the monocle code, and the
as_ref plus deref of the maximized window is dropped (Window is Copy), as on
KDE. Item 7 of the Windows list in core-model.md section 7.
BEHAVIOUR: only the text of two error messages, shown if a command asks to
toggle maximize with nothing maximized. e2e gate: none needed beyond
maximizing. Verified: Windows clippy -D warnings via tools/fast-check PASS.
The foreground lookup and the search/removal are split as on KDE:
remove_focused_floating_window(): foreground handle, then
remove_floating_window(window_id). KDE's version also focuses the previous
floating window before removing; the Windows one does not and still does not,
so the split is the only change (the call is the hook the shared code will
make optional). Item 6 of the Windows list in core-model.md section 7.
Not a behaviour change. Verified: Windows clippy -D warnings via
tools/fast-check PASS.
As on KDE. The Win32 error of the four lookups was never told apart: the
callers either turned it into a skip (.ok(), if let Ok, is_ok/is_err), a
default (unwrap_or_default) or a bare ?. They are now Option: .ok() goes,
Ok(..) patterns are Some(..), is_ok/is_err are is_some/is_none, and the
nine places that used ? now say ok_or_eyre("the window has no <field>")?
(IgnoreRule purge, stackbar label, the rule check in process_event, the
workspace-rule title in window_manager). WindowDetails: TryFrom<Window>
becomes From<Window> (unwrap_or_default per field, as KDE), and
visible_window_details pushes every visible window. komorebi-gui and
komorebi-bar adapt (is_some, no .ok()). Items 3 and 4 of the Windows list in
core-model.md section 7.
BEHAVIOUR: (1) komorebic visible-windows now lists a window whose title,
exe or class cannot be read, with empty strings, where it used to skip it;
(2) the error text of the ? sites changes from the Win32 error to "the
window has no <field>". Nothing else changes: the same lookups run in the
same order. e2e gate needed: commands (visible-windows, ignore-rule),
stacking (stackbar labels), lifecycle. Verified: Windows clippy -D warnings
via tools/fast-check PASS (workspace including komorebi-gui and komorebi-bar);
e2e not run.
As on KDE, the shared-looking operations of Window are the backend calls:
Window::focus(mff) -> eyre::Result<()> is backend().focus(..)?,
Window::maximize() / unmaximize() are let _ = backend().maximize(.., bool).
The Windows primitives they used to be are renamed focus_native,
maximize_native and unmaximize_native; WindowsBackend and the slide-in code
in animation/transition.rs (which is inside the focus) call those. The 40
focus call sites and 5 maximize call sites that spelled
backend().x(WindowId::from_hwnd(w.hwnd), ..) are w.focus(..)? / w.maximize()
again, the text KDE has; the two sites that only have a raw handle
(window_manager.rs, focus_manager.rs) use Window::from(hwnd).focus(..). The
result handling (let _ =) is inside the methods. Item 2 (second half) of the
Windows list in core-model.md section 7.
Not a behaviour change: every call ends in the same backend call as before.
Verified: Windows clippy -D warnings via tools/fast-check PASS.
The 21 let _ = backend().hide(WindowId::from_hwnd(w.hwnd)) / restore(..)
calls in workspace, monitor, window_manager, process_command and
process_event become w.hide_window() / w.restore_window(), the methods of
komorebi_core::ContainerWindow that the Windows Window already implements
with exactly that backend call. Same text as KDE's window.hide(). Item 2 of
the Windows list in core-model.md section 7.
Not a behaviour change. Verified: Windows clippy -D warnings via
tools/fast-check PASS.
The parameter and local called hwnd (container_for_window,
focus_container_by_window, contains_window, contains_managed_window,
container_idx_for_window, remove_window, the foreground handle locals) are
renamed window_id; the type stays isize (ContainerWindow::Id) and field
accesses (window.hwnd) are unchanged. Item 1 of the Windows list in
docs/dev/core-model.md section 7.
Not a behaviour change. Verified: Windows clippy -D warnings via
tools/fast-check PASS.
Class (b) of the workspace.rs classification: Workspace::hide returns
nothing, as the Windows one does; the KDE version returned an eyre::Result
whose doc said it never failed (a failing update of a scrolling workspace is
logged, not returned). The tests that called it drop the ? and unwrap, and
the empty Errors section of its doc goes. No behaviour change.
Verified: KDE cargo test -p komorebi --lib --tests (native, lite env):
630 passed, 0 failed. Not run: doc tests, VM suites.
Class (b) of the workspace.rs classification: Workspace::new_container_for_window(Window)
returns nothing, as the Windows one does; the KDE version took &Window and
returned an eyre::Result that was always Ok. The four callers and the
tests drop the & and the ? or unwrap. No behaviour change.
Verified: KDE cargo test -p komorebi --lib --tests (native, lite env):
630 passed, 0 failed. Not run: doc tests, VM suites.
Class (a) of the workspace.rs classification (docs/dev/core-model.md
section 7): is_focused_window_monocle_or_maximized, contains_window,
contains_managed_window and location_from_exe read the maximized window
with `if let Some(window) = self.maximized_window` (the Window is Copy)
instead of borrowing it, which is the Windows text of those lines. No
behaviour change.
Verified: KDE cargo test -p komorebi --lib --tests (native, lite env):
630 passed, 0 failed. Not run: doc tests, VM suites.
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.
Two unit tests in komorebi-for-kde's monitor.rs, the counterpart of the
Windows pins: a Monitor read from the monitor object of a real komorebic
state capture (e2e/lib/tests/fixtures/kfde-tiled.json, workspaces
emptied) serializes back to the same JSON value, and MonitorInformation
has its four fields. They fix the representation before any move of the
Monitor type.
Verified: KDE cargo test -p komorebi --lib monitor:: (native, lite env):
14 passed, 0 failed. Not a behaviour change.
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.
BEHAVIOUR (Windows runtime): not verified on a machine; see below.
komorebi/src/container.rs is now `type Container =
komorebi_core::Container<Window>` plus the ContainerWindow impl for the
Windows Window (id is the hwnd, exe_name is Window::exe().ok(), hide and
restore are backend().hide / .restore exactly as the container called
them, and the stacked pair is hide_with_border(false) /
restore_with_border(false) as load_focused_window used). hwnd_from_exe,
which only Windows has, is the ContainerExt trait that workspace.rs
imports. The container's operations, their order and the serialised form
are the ones in the crate (Container.locked keeps its serde default, and
the schemars schema is still named Container). The generic container
tests moved into komorebi-core; the JSON pin and the deserialize tests
stay here. komorebi-core is a path dependency, with its schemars feature
under komorebi's.
Why BEHAVIOUR: the container is the type of every container in the
state JSON and the code of every stack and tile operation, and I could
not run it. By construction the calls are the same, in the same order.
Windows e2e scenarios needed: the tiled, stack and float state
scenarios whose fixtures are e2e/lib/tests/fixtures/kfw-{tiled,stack,
float}.json (komorebic state must be byte-identical), stack/unstack and
cycle-stack commands, a stack on a monitor move, monocle and
move-to-workspace of a stacked container, and the schema check
(schema.json unchanged).
Verified: tools/fast-check windows step = nix develop cargo clippy
--workspace --locked --all-targets -D warnings: PASS (komorebi tests
compiled, not run); komorebi-core tests PASS (native); macOS fake-CC
type-check PASS (it does not use the crate). Not verified: any run of the
Windows tests or daemon.
komorebi-for-kde/komorebi/src/container.rs is now
`type Container = komorebi_core::Container<Window>` plus the
ContainerWindow impl for KDE's Window (id is the u32 id, exe_name is
Window::exe, the stacked hide and restore are the plain ones). The
operations, their order and the serialised form are the ones moved into
the crate; the tests that need the fake backend and the JSON pin stay
here. komorebi-core is a path dependency of the KDE workspace, and its
schemars feature goes with KDE's.
One difference from before: Container.locked may be missing when a
container is read (serde default), as it already could on Windows; the
JSON written is the same.
Verified: KDE cargo test --workspace --no-fail-fast (native, lite env,
includes tests/schemas.rs): 873 passed, 0 failed (878 before; the 5
container tests that moved into komorebi-core run there, 13 passed).
Not run: KDE VM suites.
New crate crates/komorebi-core, a member of the root workspace (KDE and
macOS take it by path when they adopt it). It holds Container<W>, moved
from komorebi-for-kde/komorebi/src/container.rs (KDE is the base) and
made generic: W is any type that implements ContainerWindow, a small
trait for what the container asks of a platform window (its id, the
executable name, hide and restore, and the hide and restore that
load_focused_window uses, which on Windows leave the border alone).
Container keeps no Backend calls; hiding and restoring is the window's
own business.
The serialised form is unchanged: id, locked (which may be missing when
read, as on Windows), windows with elements and focused. The schemars
schema of Container<W> is named Container whatever W is
(schemars(rename)), so schema.json keeps its definition name; a test
checks it. The tests of container.rs that need no daemon moved with it,
over a stub window, plus tests for the JSON, the hide/restore calls and
the missing locked field.
No daemon uses it yet: the next revisions converge KDE and Windows.
Verified: cargo test -p komorebi-core --features schemars (native):
13 passed, 0 failed. Not run: Windows, KDE, macOS builds (nothing
depends on the crate yet).
Before the container moves into a shared crate: a test that fixes the
serialised form of the Windows Container (id, locked, windows with
elements and focused) for an empty container, next to the existing
deserialize test, so the move cannot change what `komorebic state`
prints.
Verified: not run (Windows tests do not run on Linux); type-checked by
the Windows clippy gate at the end of this stack.
Before the container moves into a shared crate: a test that fixes the
serialised form of komorebi-for-kde's Container, field by field (id,
locked, windows with elements and focused), for an empty container and
for one with two windows, so the move cannot change what `komorebic
state` prints.
Verified: KDE cargo test -p komorebi --lib container (native, lite env):
50 passed, 0 failed. Not run: the rest.
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.
Monitor.id was an isize HMONITOR; it is now komorebi_backend::MonitorId (the
type WindowsBackend::monitors already returned). A serde adapter
(hmonitor_json) writes it with serialize_i64(to_hmonitor()) and reads an isize
through from_hmonitor, bit for bit, so the JSON is the same plain number as
before (including negative handles); the schemars schema is declared as isize.
serial_number_id was already Option<String> (the shared shape), so it is
unchanged. monitor::new / Monitor::new keep an isize parameter (every caller
passes an HMONITOR); the 12 uses that need the raw handle call
.to_hmonitor() (WindowsApi::monitor, wallpaper, DPI, zoomed checks, ids
compared with monitor_from_window/point). MonitorInformation.id stays isize.
BEHAVIOUR (JSON-identical by construction, not proven by running): the new
unit tests of the previous revision pin the JSON against a real capture,
but the Windows crate's tests cannot run on this host. Gate needed: any
e2e scenario that reads komorebic state or saves/loads it, and monitor
reconciliation / unknown_monitor. Verified: Windows clippy -D warnings via
tools/fast-check PASS.
Three unit tests in monitor.rs: a Monitor read from the monitor object of a
real komorebic state capture (e2e/lib/tests/fixtures/kfw-tiled.json, its
workspaces emptied) serializes back to the same JSON value; id and
serial_number_id are plain JSON values for ids including isize::MAX, -1 and
isize::MIN; MonitorInformation has the six documented fields. They fix the
representation before the type of Monitor.id changes.
The komorebi crate is Windows-only, so these compile (clippy --all-targets,
PASS) but cannot run on this host: they have NOT been run. Not a behaviour
change.
Query, ReplaceConfiguration and BorderColour become answer_query(query, reply),
replace_configuration(config) and set_border_colour(kind, r, g, b). Bodies
moved unchanged. force_update_borders is a local of process_command: the
border colour arm sets it after calling the (infallible) method, and
replace_configuration returns whether it replaced the configuration, which
is exactly where the arm used to set it (Result<bool>, where kfde's returns
Result<()>).
Not a behaviour change. Verified: Windows clippy -D warnings via
tools/fast-check PASS.
EagerFocus, ResizeWindowAxis, FocusFollowsMouse and ToggleFocusFollowsMouse
become eager_focus(exe), resize_window_axis(axis, sizing),
focus_follows_mouse(implementation, enable) and
toggle_focus_follows_mouse(implementation). Bodies moved unchanged.
Not a behaviour change. Verified: Windows clippy -D warnings via
tools/fast-check PASS.
IgnoreRule, SessionFloatRule and LayoutRatios become add_ignore_rule(identifier,
id), add_session_float_rule() and set_layout_ratios(columns, rows), the names
kfde used. Bodies moved unchanged; each arm is one self.x(..)? call.
Not a behaviour change. Verified: Windows clippy -D warnings via
tools/fast-check PASS.
ToggleWorkspaceLayer, CycleFocusWorkspace, CycleFocusEmptyWorkspace,
CloseWorkspace, FocusLastWorkspace, FocusWorkspaceNumbers and
MoveContainerToLastWorkspace / SendContainerToLastWorkspace (one method with
a follow flag, as the 20-line arms differed only by true/false) become
pub fn toggle_workspace_layer, cycle_focus_workspace(direction),
cycle_focus_empty_workspace(direction), close_workspace, focus_last_workspace,
focus_workspace_numbers(idx) and move_container_to_last_workspace(follow) in
a second impl WindowManager block in process_command.rs. The arm bodies moved
unchanged (dedented, ending in Ok(())); each arm is now one self.x(..)? call.
Same names as kfde's table in docs/dev/core-model.md where the command is the
same (focus_last_workspace and focus_workspace_numbers are Windows names).
Not a behaviour change. Verified: Windows clippy -D warnings via
tools/fast-check PASS.
KDE's Container and the Windows one already have the same method set and
signatures (add_window(Window), hide, restore and load_focused_window return
nothing; the earlier backend() switches made hide/restore the same calls).
The last field-level difference was the visibility of windows: pub on KDE,
private here. Make it pub; the Ring accessors (windows(), windows_mut())
stay.
Not converged, on purpose: Window::exe() is eyre::Result<String> here and
Option<String> on KDE; it has 33 callers that use ? or Ok(..) patterns, so
changing it is its own revision (not mechanical in the container alone);
hwnd_from_exe (2 callers in workspace.rs) and the hwnd/WindowId parameter
types wait for the shared core.
Not a behaviour change. Verified: Windows clippy -D warnings via
tools/fast-check PASS.
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.
Plan step 9 prerequisite: SessionFloatRule (39 lines), IgnoreRule (55),
NamedWorkspaceRule (21) and InitialNamedWorkspaceRule (21) become
add_session_float_rule(), add_ignore_rule(identifier, id),
add_named_workspace_rule(identifier, id, workspace) and
add_initial_named_workspace_rule(identifier, id, workspace). Bodies are
the arms' bodies, dedented, plus Ok(()). No behaviour change.
Verified: KDE cargo test -p komorebi --lib --tests (native, FakeBackend):
633 passed, 0 failed. Not run: doc tests, VM suites.
Plan step 9 prerequisite, next cluster of process_command: the 75-line
EagerFocus arm becomes WindowManager::eager_focus(exe) and the 90-line
ToggleWorkspaceLayer arm becomes toggle_workspace_layer(). Bodies are
the arms' bodies, dedented, plus Ok(()). No behaviour change.
Verified: KDE cargo test -p komorebi --lib --tests (native, FakeBackend):
633 passed, 0 failed. Not run: doc tests, VM suites.
Plan step 9 prerequisite: the multi-line arms of process_command become
methods of WindowManager. This cluster: CycleFocusWorkspace
(cycle_focus_workspace), CycleFocusEmptyWorkspace
(cycle_focus_empty_workspace), CloseWorkspace (close_workspace) and the
twin arms MoveContainerToLastWorkspace and SendContainerToLastWorkspace,
which were the same 27 lines but for the follow flag, now one method
move_container_to_last_workspace(follow). The bodies are the arms'
bodies, dedented, plus Ok(()). No behaviour change.
Verified: KDE cargo test -p komorebi --lib --tests (native, FakeBackend):
633 passed, 0 failed. Not run: doc tests, VM suites.
Pure move, no behaviour change: struct Monitor first, then
impl_ring_elements!, then MonitorInformation and its From impl, as in
komorebi/src/monitor.rs. Field order and field sets are untouched (the
derive order is the JSON order of the state, and Windows' extra fields
name, device_id and workspace_names are content, not layout; see
docs/dev/core-model.md).
Verified: KDE cargo test -p komorebi --lib --tests (native): 633 passed,
0 failed. Not run: doc tests, VM suites.
Container::add_window takes the Window by value, and hide, restore and
load_focused_window return nothing (hide and restore take &self), as in
komorebi/src/container.rs. The KDE versions returned eyre::Result that
was always Ok (their docs said so) and callers wrote ? or unwrap on it;
those are gone, as is the eyre import of container.rs. Each operation
still does what it did: the same windows are hidden and restored in the
same order. No behaviour change.
Verified: KDE cargo test -p komorebi --lib --tests (native, FakeBackend):
633 passed, 0 failed. Not run: doc tests, VM suites.
Pure move, no behaviour change: the impl blocks and methods of
komorebi-for-kde/komorebi/src/container.rs are in the same order as
komorebi/src/container.rs (hide, restore, load_focused_window,
idx_from_exe, contains_window, idx_for_window, remove_window_by_idx,
remove_focused_window, add_window, focus_window), impl_ring_elements!
follows the struct, the derive list and Default::default use the same
spelling. This makes the remaining differences (window id type, fallible
signatures) the only lines a diff shows. See docs/dev/core-model.md.
Verified: KDE cargo test -p komorebi --lib --tests (native): 633 passed,
0 failed. Not run: doc tests, VM suites.
komorebi-for-kde's Backend is now `trait Backend: komorebi_backend::Backend`
and declares only what is KDE's own: drag_origin and drag_end, apply_look,
set_border_colours, set_wallpaper and shutdown. The 26 operations that
have shared names and semantics (docs/dev/seam.md section 2.1) are the
shared trait's; KWinBackend and the KDE FakeBackend implement it directly
(supports() is true for every capability, batches are the default no-ops)
and the backend::shared module with its Shared<B> adapter is deleted. The
shared contract tests (check_all and the KDE-specific assertions) now run
against FakeBackend itself. Integration tests import the shared trait to
call the fake's operations.
No behaviour change. Coverage removed with the duplicated declarations:
the doc examples of the KDE set_opacity and set_focus_follows_mouse
(the fake tests and the shared contract still exercise both) and the
'id too wide for u32' wrapper test (the same rule is in KWinBackend raw()).
Verified: KDE cargo test --workspace --no-fail-fast, 878 passed, 0 failed
(native, FakeBackend; was 881 before this revision, the 3 removed tests
are the ones named above). Not run: KDE VM suites.
KDE's Backend returned its own WindowInfo/MonitorInfo (plain String and
bool fields) and the Shared wrapper rebuilt the shared ones from them,
the KDE fake did the reverse. The trait now returns komorebi_backend's
types (Option for what a platform may lack); the fake passes the shared
fake's values through and KWin converts its table's records with From.
The plain KDE structs stay as the view the window manager core reads
(Window::info and the monitor loaders convert with From, which fills a
missing field with empty/false and a missing 'normal' with true, exactly
what KDE always had); the shared wrapper is now a pure pass-through,
removed in the next revision. A few test assertions read the Option
fields. No behaviour change.
Verified: KDE cargo test --workspace --no-fail-fast 881 passed, 0 failed
(native, FakeBackend; the one doc test that needed a fix was re-run
and passes). Not run: KDE VM suites.
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.
The five window.maximize() / unmaximize() calls in workspace.rs become
let _ = backend().maximize(id, true/false). The trait already has the
capability query (Backend::supports(Capability::Maximize), true on
Windows), so no trait change; the Windows daemon does not need to ask, the
shared core will. WindowsBackend::maximize runs Window::maximize /
unmaximize, which keep the HIDDEN_HWNDS bookkeeping. set_opacity is NOT
switched: the adapter's set_opacity is the plain write, while
Window::transparent/opaque take the alpha from the transparency manager and
animate.
BEHAVIOUR: a dead window is skipped (IsWindow first). e2e gate needed:
maximizing, commands, workspaces. Verified: Windows clippy -D warnings via
tools/fast-check PASS; e2e not run.
Every WindowsApi::window_rect(hwnd) in window_manager.rs becomes
backend().frame(WindowId::from_hwnd(hwnd)). WindowsBackend::frame is
Window::window_rect, i.e. the same DWM call with the Win32 error kept; the
callers' ?, ok(), unwrap_or_default() and is_ok_and() behave as before (only
the error text can differ: a window that died meanwhile reports WindowGone).
BEHAVIOUR: none intended; e2e gate needed: commands, layouts, workspaces, stacking. Verified: Windows clippy
-D warnings via tools/fast-check PASS; e2e not run.
Every WindowsApi::window_rect(hwnd) in border_manager/border.rs becomes
backend().frame(WindowId::from_hwnd(hwnd)). WindowsBackend::frame is
Window::window_rect, i.e. the same DWM call with the Win32 error kept; the
callers' ?, ok(), unwrap_or_default() and is_ok_and() behave as before (only
the error text can differ: a window that died meanwhile reports WindowGone).
BEHAVIOUR: none intended; e2e gate needed: borders. Verified: Windows clippy
-D warnings via tools/fast-check PASS; e2e not run.
Every WindowsApi::window_rect(hwnd) in process_event.rs becomes
backend().frame(WindowId::from_hwnd(hwnd)). WindowsBackend::frame is
Window::window_rect, i.e. the same DWM call with the Win32 error kept; the
callers' ?, ok(), unwrap_or_default() and is_ok_and() behave as before (only
the error text can differ: a window that died meanwhile reports WindowGone).
BEHAVIOUR: none intended; e2e gate needed: commands, lifecycle, resize, move. Verified: Windows clippy
-D warnings via tools/fast-check PASS; e2e not run.
Every WindowsApi::window_rect(hwnd) in animation/ghost.rs becomes
backend().frame(WindowId::from_hwnd(hwnd)). WindowsBackend::frame is
Window::window_rect, i.e. the same DWM call with the Win32 error kept; the
callers' ?, ok(), unwrap_or_default() and is_ok_and() behave as before (only
the error text can differ: a window that died meanwhile reports WindowGone).
BEHAVIOUR: none intended; e2e gate needed: animation scenarios. Verified: Windows clippy
-D warnings via tools/fast-check PASS; e2e not run.
Every WindowsApi::window_rect(hwnd) in border_manager/mod.rs becomes
backend().frame(WindowId::from_hwnd(hwnd)). WindowsBackend::frame is
Window::window_rect, i.e. the same DWM call with the Win32 error kept; the
callers' ?, ok(), unwrap_or_default() and is_ok_and() behave as before (only
the error text can differ: a window that died meanwhile reports WindowGone).
BEHAVIOUR: none intended; e2e gate needed: borders. Verified: Windows clippy
-D warnings via tools/fast-check PASS; e2e not run.
Every WindowsApi::window_rect(hwnd) in process_command.rs becomes
backend().frame(WindowId::from_hwnd(hwnd)). WindowsBackend::frame is
Window::window_rect, i.e. the same DWM call with the Win32 error kept; the
callers' ?, ok(), unwrap_or_default() and is_ok_and() behave as before (only
the error text can differ: a window that died meanwhile reports WindowGone).
BEHAVIOUR: none intended; e2e gate needed: commands, resize. Verified: Windows clippy
-D warnings via tools/fast-check PASS; e2e not run.
Every WindowsApi::window_rect(hwnd) in animation/ghost_dispatcher.rs becomes
backend().frame(WindowId::from_hwnd(hwnd)). WindowsBackend::frame is
Window::window_rect, i.e. the same DWM call with the Win32 error kept; the
callers' ?, ok(), unwrap_or_default() and is_ok_and() behave as before (only
the error text can differ: a window that died meanwhile reports WindowGone).
BEHAVIOUR: none intended; e2e gate needed: animation scenarios. Verified: Windows clippy
-D warnings via tools/fast-check PASS; e2e not run.
KDE's Backend took and returned bare u32 ids and answered
window_workspace and current_workspaces without a Result. The operations
that the shared trait has now use komorebi_backend's WindowId and
MonitorId, window_workspace and current_workspaces return its Result, and
the look/drag/wallpaper methods that only KDE has take the same id types.
So the Shared wrapper no longer converts ids or results: it is down to
the window info mapping.
The window manager core keeps its u32 ids (Window { id: u32 }); the
conversion is at the backend call (Window::window_id, From<WindowId> for
Window, WindowId::from_u32 / to_u32 at the remaining call sites). KWin's
table stays keyed by u32; an id too wide for a u32 is a window it never
had (WindowGone, or None for a query). Test call sites got .into() on the
ids and unwrap on the two results. No behaviour change.
Verified: KDE cargo test --workspace --no-fail-fast (unit, integration,
doc) 881 passed, 0 failed, native with FakeBackend. Not run: KDE VM
suites.
Every WindowsApi::window_rect(hwnd) in scrolling.rs becomes
backend().frame(WindowId::from_hwnd(hwnd)). WindowsBackend::frame is
Window::window_rect, i.e. the same DWM call with the Win32 error kept; the
callers' ?, ok(), unwrap_or_default() and is_ok_and() behave as before (only
the error text can differ: a window that died meanwhile reports WindowGone).
BEHAVIOUR: none intended; e2e gate needed: scrolling. Verified: Windows clippy
-D warnings via tools/fast-check PASS; e2e not run.
Every WindowsApi::window_rect(hwnd) in pan.rs becomes
backend().frame(WindowId::from_hwnd(hwnd)). WindowsBackend::frame is
Window::window_rect, i.e. the same DWM call with the Win32 error kept; the
callers' ?, ok(), unwrap_or_default() and is_ok_and() behave as before (only
the error text can differ: a window that died meanwhile reports WindowGone).
BEHAVIOUR: none intended; e2e gate needed: scrolling pan. Verified: Windows clippy
-D warnings via tools/fast-check PASS; e2e not run.
LGUG2Z