[Quick Accent] Fix window width when descriptions are disabled

[John Surles (0utsights)]

Summary of the Pull Request

Fixes Quick Accent clipping or horizontally shifting the last character when Unicode descriptions are disabled and the character list is short.

The WinUI window width was calculated as item count × 48 DIPs, but the selector surface also has 24-DIP left and right margins and a 1-DIP border on each side. Those values reduced the usable list width. Fractional layout rounding at scaled display settings could then leave the viewport one physical pixel too narrow even after accounting for the nominal XAML dimensions.

The sizing calculation now reads the surface's live horizontal margin and border thickness and includes them in the requested window width. It also adds a 1-DIP layout-rounding allowance so the character list is not truncated at fractional display scales.

PR Checklist

• Closes: [Quick Accent] Window size too narrow when info line is disabled #49346
• Communication: I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected
  • The proposed root cause and approach were posted in the contribution thread; maintainer confirmation is still pending.
• Tests: Added/updated and all pass
  • No automated test was added because this fix connects runtime WinUI layout values and display scaling to the window-size calculation; a unit test that duplicated the XAML dimensions would not catch the integration regression.
• Localization: All end-user-facing strings can be localized
  • No strings changed.
• Dev docs: Added/updated
  • No developer documentation changes are needed for this focused layout correction.
• New binaries: Added on the required places
  • No binaries or projects were added.
  • JSON for signing for new binaries — not applicable
  • WXS for installer for new binaries and localization folder — not applicable
  • YML for CI pipeline for new test projects — not applicable
  • YML for signed pipeline — not applicable
• Documentation updated: Not applicable; there is no user-facing behavior or documentation change.

Detailed Description of the Pull Request / Additional comments

SelectorControl.xaml gives the TransientSurface a Margin=24,24,24,16, and DefaultTransientSurfaceStyle supplies a 1-DIP border on each side. For the four-character reproduction in #49346, the previous calculation requested a 192-DIP window (4 × 48). After the 48 DIPs of horizontal surface margin, only 144 DIPs remained for the list, which is exactly three character cells.

SelectorControl now exposes the computed left-plus-right surface margin and border thickness internally. MainWindow.SizeAndPosition() adds that live overhead to the character-driven width before applying the existing description minimum and monitor-width clamp. A further 1-DIP allowance covers fractional physical-pixel rounding at scaled display settings.

With four characters, the calculation reserves the complete 192-DIP list width, the 50-DIP surface overhead, and the 1-DIP layout-rounding allowance. This leaves long-list scrolling, selected-character scrolling, description sizing, monitor clamping, DPI conversion, and window positioning unchanged.

Validation Steps Performed

• git diff --check passes.
• Built PowerAccent.UI locally with Visual Studio 2026 in Debug|x64; the build completed successfully with 0 warnings and 0 errors.
• Runtime-tested with Unicode descriptions disabled and only SPECIAL enabled. Holding X and pressing Space displayed all four mapped characters (ẋ, ×, ˣ, ₓ) without clipping or scrolling.
• Reproduced the one-pixel horizontal shift with all character sets enabled at 150% and 175% display scaling.
• Retested the 1-DIP layout-rounding allowance at both 150% and 175%; all seven F characters remained stationary while cycling through the selection.
• Verified the description minimum and maximum monitor-width clamp remain in the same order after the corrected content width is calculated.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Dave Rayment (daverayment)]

Hi John Surles (@0utsights). Thanks for your contribution.

Please note that we do not accept untested PRs at this time. This is because of the number of AI-authored PRs we receive which often do not even compile.

Please supply screenshots and/or a screen recording to show that your fix works as intended.

Thanks.

[John Surles (0utsights)]

Thanks for the guidance. I've now built and tested the change locally.

Validation:

• Built PowerAccent.UI with Visual Studio 2026 in Debug|x64; the build completed successfully (exit code 0).
• Configured Quick Accent with only SPECIAL enabled and Unicode descriptions disabled.
• Held X and pressed Space, matching [Quick Accent] Window size too narrow when info line is disabled #49346.
• The popup now shows all four mapped characters (ẋ, ×, ˣ, ₓ) without horizontal clipping or scrolling.

Patched build result:

[John Surles (0utsights)]

@microsoft-github-policy-service agree

[Dave Rayment (daverayment)]

Thanks for the screenshot. I've built this myself now. Unfortunately, I can see that there is still not enough space to accommodate the required width, which results in the character list shifting when selection changes:

Screen.Recording.2026-07-20.213455.mp4

[Dave Rayment (daverayment)]

Suggested changes to add the necessary 2 DIPs and document the update.

[John Surles (0utsights)]

Hey! Sorry, I just reviewed my version and your changes and realized I totally overlooked it. Thank you for pointing it out and fixing it!

[Dave Rayment (daverayment)]

Thanks for integrating the suggested updates.

Just to wrap things up, could you update the PR description to account for the change in the calculation, please? Otherwise, this now looks fine.

[Dave Rayment (daverayment)]

Sorry, after some subsequent testing, it looks like there are still issues with the selection window not being wide enough on some displays when scaling has been applied.

For example, on my laptop display at 125% scaling, everything's fine, but on a 4K external monitor, the problem reoccurs:

QA4K175.mp4

[Dave Rayment (daverayment)]

John Surles (@0utsights) I think the final issue is because of fractional pixel values involved in the layout when the display is scaled. This is fine at some scales (where the fractional value is rounded down), but not in others (where it's rounded up, leading to the window being one pixel too narrow for the content).

I'd suggest:

1. Adding this new field to MainWindow.xaml.cs before the constructor:

    // Handles the fractional pixels that may occur with scaled displays from truncating the character list.
    private const double LayoutRoundingDip = 1;

In SizeAndPosition() in the same file, adding this rounding fix to the content width calculation, i.e.:

        double contentWidthDip = (ViewModel.Characters.Count * ItemWidthDip) + Selector.HorizontalSurfaceOverheadDip + LayoutRoundingDip;

What do you think? I've tested this and it works for my displays at 125% and 175%, but please corroborate on your own system.

[John Surles (0utsights)]

Hey! I was able to reproduce the issue at both 150% and 175% scaling. I then tested your suggested change, and it works great at both scales. I’ll apply the change and update the PR. Thanks for investigating this!

[Dave Rayment (daverayment)]

Thanks for the update and for testing. Just minor comment nits to clear up now, I think.

[moooyo]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).