04. The redesigned interface, displayed and driven

Date: 2026-08-09 Verdict: Two defects found, both fixed and reverified. The layout is otherwise sound.

The first pass since the interface was rebuilt. It was carried as debt: the redesign had changed every line of interface code without a single window ever having been displayed.

About this edition. The original record of this pass is an internal working document, in French. This is a full English edition prepared for publication, faithful to it and adding nothing. The original is archived unchanged.

---

A warning about the environment, before any results

This pass was requested as the session on a real Windows machine that the task list had been waiting for. It is not one. The environment is a sandbox again, and that has to be said before the results are read rather than buried at the end.

So the five items the task list holds open remain untested. Refresh rate preserved across a real change, a genuine driver rejection, how long the interface freezes during a real switch, rendering at 125 and 150 percent, and restoring native on a display that actually moved. None of the five is closed by this report. They still need real hardware, which report 06 eventually provided.

What this pass could do, and did: display the windows, drive them with real input, measure the layout, and exercise the paths the virtual driver happens to make reachable.

---

Summary

---

D9. The dark title bar never applied

Symptom. Both windows displayed with a white title bar over fully dark content.

What the task list assumed. That it might need reapplying after the window is shown, or hiding and reshowing the window to force a redraw.

The conclusion was right. The reason was not. This is not a redraw problem.

The real cause, measured. The toolkit creates a temporary native window when the app asks a hidden window for its handle, then destroys it and creates a different one when the window is actually shown. The handle captured during initialisation is therefore already dead by the time anybody sees the window, and the attribute went with it.

A dedicated probe, reproducing the app's initialisation order exactly:

  handle while hidden        : one value
  set the dark attribute     : succeeded
  read it back               : applied

  handle after showing       : a different value, it changed
  read the attribute back    : invalid handle error

  set on the live handle     : succeeded
  read on the live handle    : applied

The error returned is the one Windows gives for a handle that no longer refers to anything. The window the attribute had been given to does not exist any more.

A control test first. The same call made from an outside process against the app's already visible window returns success and darkens the bar immediately. The API works in this environment, so this was never a sandbox limitation. Establishing that before blaming the code is what made the diagnosis possible.

The fix. The call before the window is shown is kept, for the Windows builds where the handle does survive and the bar is therefore dark from the first frame. A second call was added once the window is mapped, against a freshly resolved handle. In this environment the first does nothing and the second does the work.

Verified. Relaunched from source. Dark title bar on the main window and on the FAQ, produced by the app itself with no outside intervention.

---

D10. The status strip clips the worst message from 125 percent up

Symptom. Not visible here, because the sandbox offers 96 DPI only. Found by measuring, which is what the task list had explicitly asked for.

The strip is a fixed height frame of 52 scaled pixels that does not resize to its content, and the label inside wraps at 288.

The measurement. Height the label needs for the longest message the app can produce, at three scales:

The cause is not a scaling error. At a wrap width of 288 the message runs to four lines, and line height climbs in font sized steps while the box climbs continuously. The ratio degrades at every step.

The message in question is the one that tells the user their resolution is not registered with their graphics driver, and to go and add it. It is the most useful message the application produces, because it is the only one that tells a user how to fix their own problem, and it was the one being cut.

The fix. The wrap width goes from 288 to 320. The usable width inside the window is 378, set by the wordmark rather than by the tile grid, so the room exists.

The same message then falls to three lines:

A full sweep across all thirteen messages the app can produce, at all three scales, finds none that overflow. The reserved height was not touched, so the geometry at 100 percent is unchanged.

The limit of this verification. The figures at 125 and 150 percent come from forcing the toolkit's scaling factor and asking the widget how tall it wants to be. That is a measurement, not a capture of a display genuinely set to those scales. The task list item stays open. Report 06 later closed it on real displays, and found the fix holds.

---

The read back check, reverified under real conditions

The virtual driver accepts everything and applies nothing. That is exactly the condition the read back check exists to catch, and this time it was exercised by a real click on a real tile rather than by calling the function directly.

Clicking the 1920 x 1080 tile, with the display at 2560 x 1407:

The driver accepted 1920 x 1080 but the display is still 2560 x 1407.

in the error colour. The driver had returned success.

An independent check through a separate system interface, before and after the click, without going through the app's code at all:

before : 2560 x 1407 at 32 Hz
after  : 2560 x 1407 at 32 Hz

Two independent sources agree. The app did not lie. This confirms the original defect a second time, now through the complete interface rather than an isolated call.

The refresh rate reading is correct too. The app displays 32 Hz and the independent check reports 32. It did not fall back to 60. That does not replace testing preservation across an effective change, which remains impossible here.

---

The input rule

Direct verification of the pattern used by the custom resolution handler.

Nine of nine. And the control that justifies the rule: with the Unicode aware shorthand in place of the ASCII pattern, all three non ASCII forms are accepted.

---

Invariants, no regression

After both fixes, against the source:

• Imports are exactly five, all from the standard library.
• No occurrence of any subprocess, shell, browser launching, URL or socket facility, and no file opening call. The only textual match is the header comment that states the rule.
• The source compiles.

Neither fix touches the resolution setting function, the display mode structure, the field flags, or the pack order.

---

What this pass did not test

Beyond the seven standing limitations of the sandbox:

1. The packaged executable. Everything here was done from source. Neither build was rebuilt or run.
2. The security pass on the one directory build, still open at this point. Report 05 covers it.
3. Rendering at 125 and 150 percent. Measured, not observed.
4. Leaks, memory and startup. Out of scope for this pass.
5. Multiple monitors.
6. The generated icon. The asset generator had not been run, so the small sizes remained unjudged. Report 05 judged them, and found a problem.