Settings window layout is broken by high Windows DPI #2238

New issue

Open

opened 2026-02-20 22:02:42 -05:00 by deekerman · 4 comments

deekerman commented

2026-02-20 22:02:42 -05:00

Owner

Originally created by @quixoticaxis on GitHub (Jun 2, 2021).

Describe the bug
The left stack panel of the "Settings" window does not stretch to content's width.
The Windows DPI for the display hosting the window on the screenshot below is 175%. The layout is also broken at 150%. The layout is correct at 100%.
I checked it in Mumble - Lite, Classic themes, and also checked with None theme option.

Steps to Reproduce
Steps to reproduce the behavior:

Set Windows DPI to 150% or 175%.
Open the "Settings" window
The contents of the left stack panel are cut.

Expected behavior
The stack panel correctly stretches to show the non-cut content. I expect the panel to fit the largest item.

Screenshots

Desktop:

OS: Windows 10 Pro 64 20H2 (version 10.0.19042.985)
Version: Mumble (1.3.4)

Additional context
It looks like for some reason the contents of the buttons are DPI aware and thus become bigger with higher DPI, but the stack panel either ignores DPI or simply has a fixed width.

Originally created by @quixoticaxis on GitHub (Jun 2, 2021). **Describe the bug** The left stack panel of the "Settings" window does not stretch to content's width. The Windows DPI for the display hosting the window on the screenshot below is 175%. The layout is also broken at 150%. The layout is correct at 100%. I checked it in Mumble - Lite, Classic themes, and also checked with None theme option. **Steps to Reproduce** Steps to reproduce the behavior: 1. Set Windows DPI to 150% or 175%. 2. Open the "Settings" window 3. The contents of the left stack panel are cut. **Expected behavior** The stack panel correctly stretches to show the non-cut content. I expect the panel to fit the largest item. **Screenshots** ![2021-06-02](https://user-images.githubusercontent.com/14001556/120463245-61ee6b80-c3a4-11eb-8024-3b92bed78267.png) **Desktop:** - OS: Windows 10 Pro 64 20H2 (version 10.0.19042.985) - Version: Mumble (1.3.4) **Additional context** It looks like for some reason the contents of the buttons are DPI aware and thus become bigger with higher DPI, but the stack panel either ignores DPI or simply has a fixed width.

deekerman added the

client

bug

labels

2026-02-20 22:02:42 -05:00

deekerman commented

2026-02-20 22:02:43 -05:00

Author

Owner

@quixoticaxis commented on GitHub (Jun 2, 2021):

Seems related to #3792. Using compatibility DPI settings fixes the layout, but makes everything blurry.

@quixoticaxis commented on GitHub (Jun 2, 2021): Seems related to #3792. Using compatibility DPI settings fixes the layout, but makes everything blurry.

deekerman commented

2026-02-20 22:02:44 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Jun 2, 2021):

I have seen a similar effect on Linux without using any high DPI. Some entries are just abbreviated.

Thus I strongly suspect that the sidebar simply has a fixed width and everything that exceeds it, is cut off.

@Krzmbrzl commented on GitHub (Jun 2, 2021): I have seen a similar effect on Linux without using any high DPI. Some entries are just abbreviated. Thus I strongly suspect that the sidebar simply has a fixed width and everything that exceeds it, is cut off.

deekerman commented

2026-02-20 22:02:44 -05:00

Author

Owner

@quixoticaxis commented on GitHub (Jun 2, 2021):

I have seen a similar effect on Linux without using any high DPI. Some entries are just abbreviated.

Thus I strongly suspect that the sidebar simply has a fixed width and everything that exceeds it, is cut off.

I don't know Qt, but I checked the menu markup and it seems to use resize policy with horizontal stretching.

@quixoticaxis commented on GitHub (Jun 2, 2021): > I have seen a similar effect on Linux without using any high DPI. Some entries are just abbreviated. > > Thus I strongly suspect that the sidebar simply has a fixed width and everything that exceeds it, is cut off. I don't know Qt, but I checked the menu markup and it seems to use resize policy with horizontal stretching.

deekerman commented

2026-02-20 22:02:44 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Jun 2, 2021):

Then maybe the size calculation is broken 🤷

@Krzmbrzl commented on GitHub (Jun 2, 2021): Then maybe the size calculation is broken :shrug: