v1.1.0-dev.99: The audit release

v1.1.0-dev.99: The audit release

Pre-release off the dev branch. Builds on v1.1.0-dev.98.

A full read of the app against its own docs, with every change checked
by a fresh review and driven through the UI probes. Nothing here changes
how a profile is stored. Everything you saved keeps working.

Keys do one thing

Two keyboard handlers had been answering the same keys. Enter in the
profile list loaded the profile twice. Enter in the details pane loaded it
and opened the window editor. Delete on a window removed it and asked
whether to delete the whole profile. Each key now has one owner.

The keyboard also follows the mouse now. Click a window on the canvas, or
any button in the details pane, and the next key goes there. Before, a
click on the canvas left the keyboard on the profile list, so j walked
the profiles and Delete went to the wrong place. A box you're typing in
keeps its focus, so a click on the canvas mid-rename doesn't commit the
name under your drag.

x removes the selected window in the visual editor too, matching the
list view, and ? says so.

Update keeps your colours and your rules

Update re-captures your desk, and it kept the hotkey, the binding, the
Docking Bays and the rollback trail. It dropped every per-window colour
and every "Recognise by" rule. They survive now, carried across by the
window's identity the same way the bays are.

"Reset colour" and setting a rule back to "exact" never stuck either. The
save put the old value straight back. It doesn't any more.

The Load button runs your postLoad hook

A profile's postLoad command ran from the tray, from a hotkey, and from
the command line. From the Load button in the app it never ran. Now it
does. A display-only preset loaded from that button also says what its
display step did, instead of "restored 0/0".

Docking Bays in the list view

Rows that belong to a bay carry its name as a chip, and the rows are
marked along the left edge, so a bay is visible without switching to the
visual editor. Grouping and moving still happen on the canvas.

Smaller things

• Four command-palette entries clicked buttons that no longer existed. They
  work, and the palette gained Display settings, Hotkey, Toggle view, Help
  and Report a bug.
• The welcome card used two colours that were never defined.
• --load="Profile" --show from the command line now raises the window as
  well as loading.
• Every profile's $schema pointed into a private repo. It points at
  dougfessler.com
  now, so a hand edit gets autocomplete, and the schema matches what the
  app writes.
• The README, the technical design doc and the tutorial no longer describe
  a DPI rescale, Alt to snap, or an MIT licence. None of those has been true
  for a while.

Install

Auto-updates from dev.53 and later. Otherwise unzip and run.

v1.1.0-dev.98: Docking Bays

v1.1.0-dev.98: Docking Bays

Pre-release off the dev branch. Builds on v1.1.0-dev.97.

The feature is called a Docking Bay

dev.97 shipped it as a Bay. It's a Docking Bay now. The app says so
everywhere you can see it: the "Group into Docking Bay" button, the badge
on the strip below the canvas, every tooltip, and the History entries.

Nothing about your profiles changes. The grouping is stored the same way,
so bays you made in dev.97 come back exactly as they were under the new
name. There's nothing to migrate and nothing to redo.

The tutorial
has a Docking Bays topic of its own now, rather than a few paragraphs
inside the visual editor page.

The name box got its room back

The wider badge left the name reading "Visual Studi" with the rest cut
off. The strip was sharing its width with a spacer that grows just as
eagerly as the name does. The name never got more than half the row.
The spacer is a fixed gap now.

Install

Auto-updates from dev.53 and later. Otherwise unzip and run.

v1.1.0-dev.97: Bays, and the end of the FancyZones zones

v1.1.0-dev.97: Bays, and the end of the FancyZones zones

Pre-release off the dev branch. Builds on v1.1.0-dev.96.

Group windows into a Bay and move them as one

A profile is a flat list of windows. Arrange three of them the way you
like, then decide the whole cluster belongs on the other monitor. Now
you're dragging them one at a time and hoping the spacing survives.

A Bay is a named group of windows inside one profile. Select two or more
in the visual editor with Ctrl-click or Shift-click, then press Group
into Bay in the strip below the canvas. There's no dialog. The name
comes from the apps inside. Two apps give you "Chrome + Code". Three or
more give you "Chrome + 2 more". A dashed outline appears under the
members with that name above its top left corner. It goes solid when the
whole Bay is selected.

Drag any member and the whole Bay goes with it, with the arrangement
inside preserved exactly. Hold Shift and the group snaps by its own
outer edges rather than by the window under your pointer. It lands flush
against a monitor edge the way a single window does.

Move to monitor… sends every member to one display and keeps the
offsets between them. It anchors the group at the target's top left work
area corner rather than the spot it held on its old display. Expect the
Bay to jump into the corner. That's also how you gather one back onto
a single screen after a drag across a seam has left half of it on the
neighbour. Ungroup drops the grouping and leaves every window exactly
where it is. Nothing leaves the profile.

Bays save with the profile and survive an Update. Re-capturing your desk
keeps the groups you set up. Every Bay action is undoable with
Ctrl+Z and turns up in History (Ctrl+H) on its own line, like
"Grouped 3 windows into Chrome + 2 more".

Loading a profile is unchanged. The members go back the way any window
does, in one pass, with nothing focused or raised on the way. A Bay is a
grouping inside the profile and the editor. Nothing about it reaches
Windows.

A plain click now selects the whole Bay

This is the habit that changes. Clicking any member selects every window
in its Bay and the strip below the canvas becomes the Bay strip: the name
in a box you can type in, the window count, Move to monitor…,
Ungroup and Remove.

To get at one member on its own, Ctrl-click it. That brings back the
ordinary window panel with Edit, Block app and the position and size
pills.

Two rough edges worth knowing about. Selecting only some of a Bay's
members gives you the ordinary multi-select strip with Group into Bay
on it. Pressing it there splits those windows off into a new Bay.
Selecting members of two different Bays and pressing it merges them.
Neither is signposted at time of writing.

The FancyZones zones are gone from the visual editor

dev.79 added a checkbox that drew your PowerToys zones on the editor's
canvas and snapped a dragged window into one. It was off unless you
turned it on. If you never ticked that box, nothing here looks any
different to you.

The checkbox, the layout picker beside it, the note about what could and
couldn't be read, and the dashed numbered rectangles are all out.
Dragging a window onto a zone no longer moves it there and no longer
resizes it to fit. This is a removal rather than a rework. There's no
setting that brings it back.

It worked by reading PowerToys' own config files, a private format that
another app owns and rewrites on its own schedule. It needed PowerToys
installed with a layout covering the monitors in your profile. Some
layout types it could only ever draw approximately.

Shift-drag snapping in the editor is untouched. Hold Shift while
dragging and a window still snaps its edges and centers to nearby monitor
edges and to the other windows in the profile, exactly as it did before
dev.79 and during it. The one thing Shift-drag lost is landing on a zone.
Snapping monitors with Shift in Display settings is a different feature
and isn't affected.

Your PowerToys setup is untouched too. WLM only ever read those files and
never wrote to them. No zones were changed, moved or lost. FancyZones'
own drag-snap in Windows works the way it always did. PowerToys is still
in the Companion Software list and still worth having. Your saved
profiles need nothing done to them either.

Live mode stops forgetting what you set by hand

Found while building Bays. It predates them. Moving a window while a
profile was in live mode rewrote that window's saved entry from what the
watcher saw on your desk. The watcher reports geometry and knows nothing
about the things you set in the editor. A per-window color set from the
window editor was dropped the first time you nudged that window.

Anything only the editor can set now survives a live move: the color, the
match rule, and the Bay the window belongs to.

Smaller things

Resizing isn't group aware. Dragging a member's corner resizes that one
window and leaves the rest where they are. The outline follows.

The list view doesn't know about Bays. Members show as ordinary rows with
no name and no sign they belong together. Bays live in the visual editor
for now.

A Bay can span two monitors. Each member picks its own display from its
own center, the same as a lone window does. A drag across a seam can
leave a group on both. That's allowed and it's saved that way. Move to
monitor… is how you gather it up again.

Install

Auto-updates from dev.53 and later. Otherwise unzip and run.

v1.1.0-dev.96: Snapping is yours to ask for, and WLM stops grabbing focus

v1.1.0-dev.96: Snapping is yours to ask for, and WLM stops grabbing focus

Pre-release off the dev branch. Builds on v1.1.0-dev.95.

Clicking in another program no longer pulls WLM to the front

Reported as clicking something in a completely different app focusing
WLM. It happened while one of WLM's dialogs was open, and only when that
app overlapped WLM's window.

A dialog disables the window behind it. That is what makes it modal, and
it is also why a click on that window cannot be noticed the ordinary way,
so WLM watched the mouse button and checked whether the pointer was over
its own window's rectangle. A rectangle is not the same question. Another
program sitting on top of WLM covers the same rectangle, so a click inside
that program looked identical to a click on WLM.

WLM now asks Windows which window the click actually landed on before it
does anything. If it wasn't ours, nothing happens.

Monitors snap when you ask them to

Dragging a monitor in Display settings always snapped it onto its
neighbour's edge. That sounds helpful and got in the way: the pull reaches
100 pixels, so a 200 pixel band around every edge could not be landed in
at all. If you wanted a display at a particular offset, the picker
wouldn't let you have it.

Hold Shift while dragging to snap. Let go and the monitor stays
exactly where you put it, with only the rules Windows itself enforces
(nothing overlapping, nothing floating free) able to move it. The
alignment line appears while Shift is down and goes when you release it,
so you can press and release mid-drag and watch it come and go.

Shift is already the key for nudging a selected display with the arrow
keys, and the two never get in each other's way.

The Position fields moved, and read better

They were a row on the monitor's settings card, describing the picture
drawn a long way above them and sized like the dropdowns they sat between.
They are now on the arrangement row directly under that picture, beside
the chip that says whether the arrangement is saved with the profile.

Smaller things

Hovering the resolution dropdown drew an enormous chevron across the whole
control. It also changed colour, and sank a pixel when pressed, neither of
which the two dropdowns either side of it do. All three are fixed.

The Display settings window opens wider and taller. Its old minimum size
was set for a version that had neither a picture of your desk nor a full
settings card in it.

Install

Auto-updates from dev.53 and later. Otherwise unzip and run.

v1.1.0-dev.95: The app stops zooming itself, and a pass over the display editor

v1.1.0-dev.95: The app stops zooming itself, and a pass over the display editor

Pre-release off the dev branch. Builds on v1.1.0-dev.94.

The app is no longer too zoomed in

Reported as Windows zoom double applying, and that is what it was. Page
zoom multiplies with your display's scale rather than replacing it, so a
stray zoom of 1.25 on a 125% display draws the app at 156%.

Three things made a stray zoom stick. It belongs to the page rather than
to one window, so it hit the app window, every dialog and the next dialog
before you opened it. It was written to disk, so restarting never cleared
it. And nothing in the app ever asked for it. It arrived from Ctrl and the
mouse wheel, or from Zoom In and Zoom Out on the menu Electron installs
for any app that never sets one of its own. Those are gone, and the app
now pins its own zoom on every load, so a copy that already picked one up
repairs itself the first time you start this build.

dev.94 shipped a guard for the earlier report of this. That guard was
working from a wrong idea of how the two scales combine and could not
settle: applied once, it read its own output back as health and undid it,
and fed a stale reading during a zoom change it produced exactly the 156%
above. It has been removed. If you were watching crash.log for a
"renderer scale guard" line, there is nothing to watch for any more.

Reopening Display settings shows the arrangement you saved

The editor drew your desk as it is right now and then corrected itself to
the profile's saved arrangement a moment later. Most of the time that was
a flicker. When the correction could not be worked out it never arrived at
all, so the picture showed one layout while Save wrote another.

It settles the arrangement before drawing anything now. Unplugging or
plugging in a display while the editor is open also used to replace the
profile's saved positions with wherever your monitors happened to be,
which the next Save then wrote. Those positions are kept.

Drag a monitor and see what it lines up with

Monitors have always snapped onto each other's edges when you drop them.
Nothing showed it, so the box followed your pointer exactly and then
jumped on release, which reads as the editor arguing with you.

The monitor now moves to the snapped position while you are still
dragging, with a line down the edge it has found. Let go and nothing
moves, because it is already there.

Type a monitor's position

The picker is quick and imprecise, and the arrow keys move by a step you
have to go and set in Settings. There are now Position fields on the card,
so you can put a display at an exact offset.

Typing does not snap. A number pulled onto a nearby edge is a field that
ignores what you typed. A position that would leave a display touching
nothing is still refused, because Windows keeps no arrangement like that,
and the picker now says so rather than quietly redrawing a number you did
not type.

The primary display's fields are switched off. It is the origin every
other position is measured from, so it always sits at 0, 0. Drag it to
move everything else around it.

Custom resolutions stops appearing on ordinary monitors

With a virtual-display driver installed but its display not currently up,
the "Custom resolutions…" button appeared on real monitors it has nothing
to do with. Opening a profile whose saved resolution that monitor cannot
currently do was enough to bring it out, which is an everyday thing for a
profile written against another desk.

The button is about the driver's own displays now. Registering a size
before that display comes back still works, since that is when it matters
most.

Smaller things

The resolution dropdown was drawn a size and a shade apart from the
Orientation and Refresh rate dropdowns either side of it. Closed, it now
matches them exactly.

Headings, window titles and dialog names are Title Case throughout. Every
Settings tab was already, apart from Companion Software, and the keyboard
shortcut list was entirely lowercase.

Install

Auto-updates from dev.53 and later. Otherwise unzip and run.

v1.1.0-dev.94: Zoom changes stop moving your windows

v1.1.0-dev.94: Zoom changes stop moving your windows

Pre-release off the dev branch. Builds on v1.1.0-dev.93.

Three fixes, all about what a zoom change is allowed to move.

Layouts saved at one zoom now load exactly as saved

A layout saved at 100% zoom and loaded at 150% came back with every
window half again too big and half again too far from its corner.

The restore math rescaled positions and sizes by the zoom ratio, on the
theory that a window's apparent size should follow the zoom. The theory
missed one thing: the monitor's physical pixel grid, the grid your
windows actually live in, does not move when the zoom changes. Only the
logical one does. So the rescale moved windows that had no reason to
move.

Saved coordinates are physical pixels and go back as physical pixels
now, with no rescale in either direction. Save at 100%, load at 150%,
and every window lands exactly where you put it, at exactly the size
you gave it. Same for any zoom change in either direction, and for
windows moving between monitors that run different zooms.

The app's own controls at zoom other than 100%

Reported as the app's buttons rendering the wrong size at any zoom past
100%, even after a restart. On real displays every path we could
measure behaves correctly, so this targets the one desk configuration
we could not reproduce here: virtual displays whose driver reports a
scale the app's renderer disagrees with.

The app now checks its renderer's scale against the display's real
scale when windows open, move, or sit through a zoom change, and
corrects the page when the two disagree. Where they already agree,
which is every desk we could measure, the check does nothing. If your
desk still shows the wrong sizes on this build, the app's crash.log
(in the app's data folder) will carry a "renderer scale guard" line
naming both numbers, which tells us exactly what to fix next.

The resolution dropdown no longer clips at the window edge

The resolution dropdown in a profile's Display settings could open
with its tail cut off by the bottom of the window, the last rows
unreachable. The panel's minimum height could exceed the space left
below the button it opens from. The available space is the limit now:
the panel fits the window wherever it opens, near the bottom edge or
anywhere else.

Install

Auto-updates from dev.53 and later. Otherwise unzip and run.

v1.1.0-dev.93: You can pick a resolution again

v1.1.0-dev.93: You can pick a resolution again

Pre-release off the dev branch. Builds on v1.1.0-dev.92.

One fix. Reported as "it's not possible to select a resolution in the
display settings, it just closes when hitting any input".

The Resolution dropdown closed itself the moment it opened

In a profile's Display settings, the Resolution control is a dropdown
with a search box. Pressing it could flash the list open and shut again
in the same instant, and nothing you hit changed that. The same dropdown
also closed on the first wheel tick if you tried to scroll its list.

The dropdown is pinned in place on screen, so it closes itself when the
page scrolls underneath it. That close was wired to every scroll event,
including the list scrolling inside the dropdown. Two things fell out of
that:

• Opening the dropdown scrolls its list to bring your saved resolution
  into view. That scroll event lands a beat after the dropdown opens, so
  the dropdown read its own opening as the page moving and closed.
• Scrolling the list with the wheel fired the same event, so a list too
  long to fit could never be scrolled.

It only bit on desks where the mode list is long enough to scroll. A
display driver offering a dozen modes never scrolled, so the dropdown
worked. A virtual display offers hundreds of modes and a saved
resolution sits well down that list, so it fired every time.

The dropdown now closes only on scrolling that starts outside it.
Scrolling the page still closes it, which is the reason that close
exists. The same dropdown also lives in Settings under "Zoom to
resolution rules", and gets the same fix there.

Install

Auto-updates from dev.53 and later. Otherwise unzip and run.

v1.1.0-dev.92 — Apply now stops failing on settings you already had

v1.1.0-dev.92 — Apply now stops failing on settings you already had

Pre-release off the dev branch. Builds on v1.1.0-dev.91.

Two display-editor fixes, both reported against dev.91 and both caused by
changes that shipped in it.

"Reported success but is still 1440×2560 portrait"

Pressing Apply now could report a failure against a display nothing had
changed. The guess in the report was close: the settings really were the
ones the display already had, and it tried to apply them anyway.

The refresh-rate control offers "Highest this size offers", which means
no particular rate. With one display selected that is what got stored.
With several selected, each display's draft went through a step that
resolves the choice against that display's own mode list, and that step
turned "no particular rate" into a specific number.

A draft carrying an explicit rate is a draft that differs from a display
already sitting on a lower one. So the check that skips work when a display
is already in the requested mode was bypassed, a real mode change was
attempted for a request nobody made, and when the driver kept its rate the
failure was reported.

It was reported against the size, because the message printed width,
height and orientation and never the refresh rate. So it pointed at the one
thing that was identical, which is what made this look like the display
refusing settings it already had.

Both halves are fixed. "Highest this size offers" stays unasked-for all the
way to the apply, where the rate is chosen at the display. And the message
names what actually differs:

\.\DISPLAY1 reported success but is still 1440×2560 portrait at 59 Hz
rather than 60 Hz.

The dialog flickering when you click a monitor

A monitor carrying a resolution its driver no longer offers shows the
by-hand width and height inputs, so that card is taller than the others.
Those inputs stopped reserving space in dev.91, which is what removed 58px
of permanently empty height from this dialog, and the cost was that the
dialog now had to resize when such a card appeared.

Clicking between two monitors measured, on this desk:

703 -> 560 -> 738 -> 703 -> 560 -> 738 -> ...

560 is the dialog's own minimum height. A card measured mid-rebuild is
briefly almost empty, so the window collapsed to the floor, overshot, and
settled again on every click.

Once a dialog is on screen it only grows now. Making room for a taller card
is the point. Shrinking is what had no honest reason: content that is
momentarily smaller is usually content that is momentarily incomplete, and
a dialog you are working in should not chase it. The same click now reads
703 -> 738 and stops.

Install

Auto-updates from dev.53 and later. Otherwise unzip and run.

v1.1.0-dev.91 — Dialogs that open the right size, and a Settings tab worth reading

v1.1.0-dev.91 — Dialogs that open the right size, and a Settings tab worth reading

Pre-release off the dev branch. Builds on v1.1.0-dev.90.

Five rounds of feedback in one release. Three of the reports were about
things an earlier round of this same release had broken, and two were
symptoms reported a second time after being called fixed. Those are called
out below, because how they got through is more useful than the fixes.

Display Settings

The dialog scrolled with visible blank space under the options. The cause
was 58px of deliberately reserved empty height: the by-hand resolution
inputs kept their box while hidden, and the note under them held a
three-line floor. Both were there so the dialog would not resize when a
control appeared, and both were paid for on every open whether or not
anything appeared. They collapse now and the window re-fits instead.

Measured on one desk: the dialog went from 734px to 667px tall, and the
room it had left under its height ceiling went from 4px to 71px. That
headroom is what decides whether it scrolls on a smaller app window.

Monitors nudge 10px per arrow key now instead of 100px, and the step is
yours to set in Settings → Auto-activation. Hold Ctrl for a tenth of it.
100px was a coarse place to leave a monitor and it could not be made finer.

With several monitors selected, every option now shows the value they
share, or says Multiple when they differ. Orientation and Refresh rate
had no readout at all before. Orientation was also lying: with more than
one display picked it claimed Landscape for a group that might be entirely
portrait.

Rotating several displays at once was impossible, and said nothing about
it. Picking Portrait came back landscape for every display, so the draft
matched their current state and the control snapped back on the next
redraw.

The heading row and the action buttons have air around them, and the
"Display-only preset" checkbox has a shorter label with a tooltip that
explains what the preset actually does.

Settings

The companion software tab was rebuilt. Each row now offers Install,
Update, Uninstall and Learn More, and nothing else. The Microsoft Store
button is gone, because one catalog entry in five had a store listing and a
button that appears on a single card is worse than no button.

Update no longer appears at all on something you do not have, and it is
disabled when the app is already current. That second half needed a
different fix than the obvious one: the button was not lying about being up
to date, WLM had simply never asked. Opening the tab asks winget now, so
the button reflects something real. Where there is an update, the pill
names the version you would get.

Rows sort by what there is to do about them: updates first, then what you
have, then what you do not. PowerShell 7's missing Uninstall button now
explains itself, which it should have from the start. It is found by
looking for pwsh.exe on your PATH rather than in the uninstall registry,
so there is no uninstaller for WLM to run.

The tab no longer locks the window up when it opens. Detection fires
three processes back to back, and on Windows each launch happens on the
calling thread. The app window is frameless, so that thread is the one
drawing it. Measured on one machine, same scan, one run each: 721ms with
a 342ms freeze inline, against a 17ms stall once the work moved to a
helper process.

Companion apps can update themselves in the background, per app, on a
cadence you set in Settings → Updates. It is honest about what it cannot
do: Windows will not let an unelevated app update a system-wide package,
and most of this catalog is system-wide. Those come back saying they need
administrator rights rather than failing quietly or retrying forever.

Settings is a fixed-size panel inside the main window now rather than a
window of its own, so it is the same size on every machine and the copy no
longer wraps short of the borders around it.

Update buttons

Auditing "make sure the update buttons work" turned up nine defects. Two
were invisible from the outside and worth naming:

The Install button in Settings did nothing at all on the normal path.
Settings opened in its own window, nothing in that window knew which update
was pending, so the button closed Settings and drew nothing.

Every update message went to the app window only. The update dialog opens
in its own window, so the one you were watching sat at "Downloading 0%" for
the entire download, and a failed install left both buttons disabled with
no error text, permanently.

Also: Microsoft.Power is fifteen characters and matches both
Microsoft.PowerToys and Microsoft.PowerShell, so one truncated winget row
put an update on the wrong app.

The app

Dialogs appear in alt-tab and the taskbar. They are owned windows,
which Windows leaves out of both unless asked, and there was no way back to
one you had tabbed away from. They stay modal.

Dialogs open at the size they need instead of appearing and then
resizing a moment later. They are measured while still hidden and shown
once the size stops moving.

The app's own alt-tab preview is legible while a dialog is open. It was
blurred by a real blur on the app's pixels, and Windows composites those
same pixels into the thumbnail.

Dropdowns near the bottom of a dialog are no longer cut off by whatever is
scrolling above them, and they flip above the button when there is no room
below.

The focused-pane outline no longer sits on top of dialogs. It was raised
above the window frame at some point, which put it above everything else
too.

In the visual editor, hold Shift to snap while dragging. Snapping used
to be on by default with Alt to suppress it, and the radius worked out to
between two and four pixels on screen, so it was real code no pointer could
reach.

Two things reported twice

The scrollbar and the Update button were both reported again after being
called fixed. In both cases the check I had written could not have failed:
one measured whether the window could stretch rather than whether the
content was the right height, and the other read back the exact property it
had just written.

Both now have checks that reproduce the report before the fix and go quiet
after it. The dialog one measures reserved empty space, so it goes red even
where the window has room to hide it. The focused-outline one asserts the
stacking order rather than the colour, and asserts the outline is still
there when nothing covers it, so removing it cannot pass either.

Install

Auto-updates from dev.53 and later. Otherwise unzip and run.

v1.1.0-dev.90 — A confirm you can see, and the message dev.89 never showed

v1.1.0-dev.90 — A confirm you can see, and the message dev.89 never showed

Pre-release off the dev branch. Builds on v1.1.0-dev.89.

Restore Defaults Asked Behind The Window

dev.89 put a confirm on Restore defaults, which drops the display
settings saved with a profile and writes that to disk. The confirm rendered
behind the editor that opened it.

Both are dialogs at the same stacking level. The confirm is declared first
in the markup, which loses on source order. It was invisible and it still
took the keyboard. The next Enter or Space answered a question nobody could
see. The answer was yes.

The stylesheet has a note about this exact trap, written when the same
thing happened to the arrangement history dialog. That did not stop it
happening again, so a check now presses the button in a real window and
asks the document what is actually on top.

The Message dev.89 Was Named For

Four of the eight arrow-key combinations on a two-monitor desk do nothing.
That is Windows' rule: along the axis two displays already share an edge
on, one direction overlaps the neighbour and the other opens a gap. Windows
keeps neither.

dev.89 said it had made the editor explain that. It had not. The message
was written and then overwritten by the very next line. It never once
reached the screen. In one of the two directions you got the plan's own
warning instead, which said a monitor "could not stay where it was" when
nothing had moved at all. Worse than silence.

It reaches the screen now:

These displays sit side by side. Up and down are the only way they can
move without breaking contact, which Windows will not keep.

And A Correction

dev.89's notes said six of eight combinations did nothing and that the
primary display was immovable in all four directions. Both wrong.

It was four of eight, and the primary has always moved. The measurement
behind that claim asked whether the nudged display's own coordinates
changed. Windows pins the primary to the origin, so for that one the answer
is no whether the desk moved or not. Asked properly, the two releases
behave identically: 10,992 combinations compared across desks of two to
four displays, zero differing outcomes.

The code that claimed to fix it did nothing, and is gone. The test written
to protect it passed against the release it was supposed to be protecting
against, which is the tell that should have been caught first. It asks
whether the arrangement changed now. It fails when the anchoring it
depends on breaks.

Smaller

Pressing ? in a dialog other than the display editor still left the
keyboard stranded. The fallback focused an element that cannot take focus.

Every checkbox and radio in the app sits on the spacing scale now, not just
the one that happened to get measured. Sweeping the Settings tabs the
spacing check had never opened found two more.

That check only ever looked at the tab Settings opens on. It walks all
seven now.

Install

Auto-updates from dev.53 and later. Otherwise unzip and run.