[Development] Trouble getting reviews in months and years

[Ilya Fedin]

On Thu, 11 Apr 2024 10:53:07 +0000
Morten Sørvig <Morten.Sorvig at qt.io> wrote:

> Hello Ilya!
> 
> > On Apr 9, 2024, at 00:17, Ilya Fedin <fedin-ilja2010 at ya.ru> wrote:
> > 
> > 
> > 2. https://codereview.qt-project.org/c/qt/qtbase/+/444859 which is
> > 1.5 years old and no review
> >   
> 
> This one could be candidate for discussion on the mailing list. There
> are two issues:
> 
> - Should Qt read Gdk settings? Should the XCB platform plugin read
> Gdk settings? The current approach is that we stick to X11-level
> settings, at least as far as DPI is concerned.

I hope the answer is yes. If it would be no, it would just block this
functionality without any good reason as there's no other API for this
on X11 (at least I'm not aware of).

> - Should Qt support DPI-based text scaling? With Qt 6 we moved to
> uniform scaling where the scale factor is applied to all UI elements.
> I think several operating systems provide a “larger text” setting in
> some form, so this is something we could look into if there is
> interest. But we have to make sure this does not result in broken UI
> (clipped text etc), so I don’t think we should jump directly to
> enabling it by default.

Well, Windows also has text scale option in system settings:
https://learn.microsoft.com/en-us/windows/apps/design/input/text-scaling
https://learn.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.uisettings.textscalefactor?view=winrt-22621

It currently gets applied only as long as one uses the default font
size. Once a custom font size is set, application no longer follows
the option which is non-consistent. Apparently this is because Windows
returns default font size multiplie by text scale factor thus using
96 * TextScaleFactor as logicalBaseDpi and interface DPI *
TextScaleFactor as logicalDpi would make it consistent (the code
already divides the default Windows font size by logicalDpi).

I don't know about macOS but wouldn't be surprised if it has a similar
option.

> All in all I don’t think I’ll +2 this change as it stands.

It's quite sad Qt already has abstractions to follows those settings
but doesn't use actually use them. I'm getting reports from end users
that application is not following their system text scaling
settings...

Would be really nice to get this covered by Qt's QFont::pointSize, as
it was meant to, rather than doing platform-specific code in
application to multiply the font size manually.

> > 6. https://codereview.qt-project.org/c/qt/qtbase/+/519479 
> > 
> > 8. https://codereview.qt-project.org/c/qt/qtbase/+/528953   
> 
> 
> These are of the “need to get around to it” category for my part.
> Adding new public API can take a lot of time/effort.

Yeah, that's why I'm asking to add another private API for the time
being. As it's private, you can remove it at any time, really. But
this would let test the feature in the time being.

> For 528953 we
> need to make sure we are not regressing other platforms, and I have
> at least one related bug I’d like to take a look at at the same time.

I made it call resize when it's actually needed: when the actual
backing store size has to be changed, rather than checking a
heusteristic like it was doing previously which not necessary changes
when actual size has to be changed. I wouldn't be surprised if it
would help with other bugs, such as QTBUG-117521.

> While we are on the topic - should we adopt a more structured
> approach to env variables like QT_WIDGETS_HIGHDPI_DOWNSCALE? 
> 
> qputenv("QT_WIDGETS_HIGHDPI_DOWNSCALE", "1”) is the go-to approach
> for enabling from application code, but as pointed out in 519479 that
> has the problem that the setting is propagated to child processes,
> for example via QDesktopServices::openUrl(). 
> 
> This could be fixed by always having a corresponding “_q_foo”
> application attribute (or similar), which would put environment
> variable users and source code users on equal footing.

Yes, Qt having lots of things controlled only via envrionment
variables is something that annoys me for a long time.

For instance, if your applciation has trouble working with native
Wayland, your only options are setting QT_QPA_PLATFORM which will
affect other applications started via QDesktopServices::openUrl, or
passing a fake -platform argument to QApplication, which is far from
being ideal either (thanks god such a way exists at least) as would
prevent the user to use -platform.

For comparison, gtk has gdk_set_allowed_backends API which exists for a
long time if not from the first version:
https://docs.gtk.org/gdk4/func.set_allowed_backends.html

Here are my bug reports related to reading of environment variables:
https://bugreports.qt.io/browse/QTBUG-115930
https://bugreports.qt.io/browse/QTBUG-119672

I was thinking about creating a bug report about Qt relying too much
on environment variables overall but never done that as existing
issues get no attention.