Skip to content

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

Pre-release
Pre-release

Choose a tag to compare

@defessler defessler released this 28 Aug 17:49

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.