Hi Jamie, thanks for looking into this!
On 2026-07-21 07:01, Jamie Fitzgerald wrote:
I have been using the Qt6/Wayland build on a HiDPI laptop, and I kept noticing dialogs where text was either getting cut off or wrapping in strange places. The one that finally made me look into it was the “Select Your Preferred User Interface” dialog. The description on the right gets clipped, and the “Toolbars” tab breaks into “Toolba / rs.”
Is that with a specific scaling factor applied?I don't see that issue in a quick test with qt6/kf6 and current master or 26.2.4 on Debian testing with KDE Plasma on Wayland with scaling set to 100%.
The main thing that made me think this is the actual cause is that the same dialogs look fine when I use SAL_USE_VCLPLUGIN=gtk3. GTK already supports height-for-width, so it recalculates the required height after the width is known. The issue seems to mainly affect VCL’s own layout path, which is being used by qt6, kf6, gen, Windows, and macOS.
FYI: For qt6/kf6, there is a work-in-progress implementation for using native Qt widgets instead of the vcl ones, see tdf#130857 [1].
This can be enabled by setting environment variable SAL_VCL_QT_USE_WELDED_WIDGETS=1. This still needs more work and most layout-related properties (like margins, alignment) aren't evaluated yet, so most dialogs don't look as visually appealing yet as they eventually should. (Dan has a work-in-progress change series in Gerrit to implement some of the logic, see changes up to [2].)
Before I start putting a lot of time into this, I wanted to ask a few
questions.
1.
Is height-for-width support something that would actually be wanted
in VCL, or was it left out intentionally because of performance or
another problem?
I don't know about the exact history, but probably it just wasn't implemented in the past without any particular reason for not doing so.
2.
Does the API above make sense, or should this be handled through the
existing GetOptimalSize() or get_preferred_size() system instead?
I haven't looked into the proposal/code in detail enough yet to give an informed enough opinion about it at this point, but what you suggest sounds reasonable at first read.
3.
Does an opt-in approach with a no-op default seem reasonable for
introducing it gradually?
That sounds reasonable to me.
4.
Has anyone attempted something similar before, or is there an old
branch or patch that I should look at?
I haven't looked into it in detail, but this relatively recent commit by Samuel mentions implementing a height-for-width algorithm for FixedText:
commit 2c2317022c9a2066918ea559a1debc84d4fdfd57
Author: Samuel Mehrbrodt <[email protected]>
Date: Mon May 18 12:10:36 2026 +0200
tdf#169418 Wrap long labels in the a11y sidebar
This makes labels in the a11y sidebar readable also on smaller
sidebar widths
by implementing a height-for-width algorithm in the FixedText
implementation.
Also needed some tweaks in the UI files to properly wrap the text.
The max-width-chars is needed for gtk3 backend since the equivalent
for our algorithm (natural-wrap-mode) is only available in gtk4
>= 4.6.
Change-Id: I187fc13b082935c550c2c792cde2c47fcafde843
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205318
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <[email protected]>
5.
Would comparing the results against GTK3 be a reasonable testing
method, or is there already a dialog layout testing setup that would
be better to extend?
Comparing against GTK 3 sounds like a reasonable approach to me in general.LibreOffice has a UI testing framework, but I'm not sure to what extent it currently supports testing the layout. (Others might be able to say more on that.)
If this sounds like a reasonable direction, I would start small. My first goal would only be the new API, FixedText, and VclBox, tested against the UI-picker dialog and a few other dialogs that currently have wrapping or clipping problems.I am not trying to submit a huge layout rewrite all at once. I mostly want to find out whether this is worth working on before I spend a lot of time going further into it.Thanks for reading, and I would appreciate any advice or background people can provide.
As you mentioned the qt6/kf6 vcl plugins earlier:Unless anyone has very good reasons to suggest otherwise, I think that switching from using vcl widgets to using native Qt widgets is the best way forward for these. This would also fix various other issues like various rendering issues/artifacts (see for example the tickets listed in "See also" for the above-mentioned tdf#130857) or the inability to handle multiple screens with different scale factors on Wayland (see tdf#141578 [3]) - at least for the part of the UI using the so-called "weld" approach, i.e. which supports the use of native widgets. (Some parts of the UI, including the toolbar and the Notebookbar currently don't use that approach yet, see e.g. tdf#163988 [4] for the Notebookbar.)
Current git master has experimental support for the qt6 vcl plugin for Windows and macOS as well, so this *might* be a potential way forward on those platforms as well. (That is still to be decided and needs further investigation.)
I definitely won't keep you or anyone else from improving the vcl widget implementation and improvements there are very welcome. But at least I myself probably wouldn't invest a huge amount of work into it right now when it's unclear to what extent it will still be used in the future.
(Personally, I think that leaving tasks to existing UI toolkits like GTK or Qt where reasonably possible makes sense instead of implementing and maintaining a full widget/UI toolkit with platform-specific code for all kinds of things in the long run.)
Michael [1] https://bugs.documentfoundation.org/show_bug.cgi?id=130857 [2] https://gerrit.libreoffice.org/c/core/+/206486/1 [3] https://bugs.documentfoundation.org/show_bug.cgi?id=141578 [4] https://bugs.documentfoundation.org/show_bug.cgi?id=163988
OpenPGP_signature.asc
Description: OpenPGP digital signature
