resize.edge_cases makes its drags from the daemon's layout and reads the
frames from the operating system: both sides of a shared edge, a horizontal
edge, a corner and an edge of the screen, with a neighbour or without. The
KDE extra keeps pointer_is_exact.
A display whose mode changes: the daemon's monitor follows, the windows
stay on a display and apart, and changed back they are where they were.
Platform.resizable_display says which display can change its mode, or None
and the scenario is skipped; KDE says None, as the virtual outputs of the
headless KWin have one mode. Platform.resize_display changes the mode.
hotplug.user_move moves a window with Platform.move_window to the second
display and checks that the daemon has it on that monitor and every window
is tiled on its display. The KDE suite runs it before the unplug and after
the replug, and the extra sent_by_the_user is gone.
monocle.focus_behaviour checks that with no-op the window keeps the work
area when the focus is moved in a direction, and with cycle another window
gets it. The KDE extra monocle_focus_behaviour is gone.
The shared rules scenario sends a window by the name of a workspace, checks
that a rule that is not initial is applied again when a window opens, and
that the daemon's global state has no rule after clear-all-workspace-rules.
The KDE extras keep the desktop numbers.
The shared placement scenario opens a window with a class and a rule that
puts the windows of that class first. The KDE extra by_app_id is gone;
by_program (foot.exe) stays.
Each komorebic query is compared with the daemon's state, before and after
a change of focus and layout, and a resize that was saved is undone by
loading it, with quick-save-resize and with save-resize. Platform gets
temp_path for the file of save-resize.
commands.layouts and layouts.run close windows from the end and open them
again with their own titles. The KDE extra layouts_by_count keeps only what
reads the daemon's log: KWin has each window where the daemon last asked.
minimize, unmanage and manage on the focused window now run through the
neutral platform. The check that the unmanaged window is centered is
neutral: inside the work area and not on a tile of the layout.
Platform.spawn takes rename_to and after: the window gives itself another
title after some seconds (a terminal escape on KDE). The scenario ignores a
title, and checks that the window is left alone while it has it, and tiled
once it has another.
The audit behind the docstrings of Platform: what each member promises
to both ports, what each port answers for another reason, what each
finding of the review turned out to be, and what is left to run on a
KDE VM and on Windows.
The scenario table has the four new scenarios, which pass on both
ports, and maximizing, which kfw has not run. The state's padding and
the frames' disagree on both ports, by 10 px on kfde and 7 on kfw.
The scenario's failure was its own: it waited for a focus that already
held. Five consecutive runs of 14 scenarios on Windows passed, hotplug
and focus_follows_mouse apart.
The last check of focus_follows_mouse fails on a Windows guest after
the setting was turned off with the pointer on a window and on again;
disable then enable works. The cause is not known, and the scenario is
unchanged.
Reported by the kfw session from a probe: the reconciliator sees the
removal and loops on it, and state lists two monitors for as long as it
is watched. It passes in some runs, so it is not a known failure; the
check stays red when it fails.
Run once on a real KWin with every tile 200 pixels too wide, and not
committed: seven checks failed, all about tiles on each other, and the
other 139 passed.
A port that cannot start with a case's rules, or orders its windows
otherwise, is recorded as a known failure for that case, and the other
cases run on. kfw does not accept the place as a JSON number, so
BEHAVIOUR.md lists the case as a known failure there.
A window kfw had cloaked is uncloaked by the stop and managed again on
the first workspace. A minimized window is left minimized and is not
managed. The lifecycle scenario counts only the windows in view.
The pointer on kfw reaches the first display only, because QMP's
absolute tablet is mapped there. The commands sweep passed in the two
runs that had the host to themselves and failed in the two that ran
beside a VM suite and a build.
kfw's 0ffc502c fixes the resize shortfall: a 60 pixel drag widens the
left tile by exactly 60. The commands sweep passes with a second
display, and rules, hotplug and lifecycle pass on a Windows guest.
The earlier sweep failures came with a kfde suite running beside it.
Checks.known_failure records a check that fails for a reason that is
to be followed up on: the suite does not fail, the totals say how many
known failures there are, and one that holds fails the suite so the
marker goes. unknown_monitor takes the reason, and core-e2e runs it
last, because the window it loses stays lost. BEHAVIOUR.md says so.
The scenario sends the focused window to monitor 7 with send-to-monitor and
move-to-monitor, which no display has, and checks that the daemon still
manages every window. A port may refuse or ignore the command, but a window
that was managed has to stay so: one that is not is left on the screen with
nothing tiling it.
It found a bug in both ports. kfw managed one window fewer than the OS had
afterwards (seen by hand on a Windows guest), and kfde failed it in
core-e2e on a real KWin: move_container_to_monitor takes the focused
container out of its workspace before it looks the monitor up, so the
error for a monitor that is not there comes after the container is gone.
It is not fixed, so the scenario is not in core-e2e, which would fail;
BEHAVIOUR.md has the finding. Its unit tests run it against a fake that
loses the window and one that ignores the command.
A table of the scenarios against the two ports, with where each result
comes from, the resize finding and its cause (kfw reads the rectangle a
drag started from when it handles the start event, about 100 ms after the
drag began, so the distance it measures is short by what the window moved
in that time, and more so for a longer drag), what the scenarios had to
allow for, and what is not covered.
Seven of the eight shared scenarios pass on a Windows 11 guest under QEMU
against kfw's daemon, as the session that ran them reports. The eighth,
resize, ran there and found that the edge moves less than the pointer; an
unmanaged window followed the same drag exactly, so the shortfall is in
what kfw does with the drag.
LGUG2Z