[Development] QTBUG-95930 / QTBUG-99546 need some attention
Morten Sørvig
Morten.Sorvig at qt.io
Fri May 20 12:31:03 CEST 2022
On 19 May 2022, at 16:32, Ilya Fedin <fedin-ilja2010 at ya.ru<mailto:fedin-ilja2010 at ya.ru>> wrote:
On Thu, 19 May 2022 14:20:05 +0000
Morten Sørvig <Morten.Sorvig at qt.io<mailto:Morten.Sorvig at qt.io>> wrote:
Looks inconclusive to me - no clear consensus either way. (I’m also
not sure if it's a bug - it’s just "the current behavior")
However, we might be able to find a way forward: the rounding policy
is also under user control with the QT_SCALE_FACTOR_ROUNDING_POLICY
environment variable. So users who wants no rounding at all (even for
apps which claim to not support fractional scale factors) can set it
to “Passthrough” to preserve the current behavior.
- Morten
It's a bug as it makes applications that clearly stated they don't
support fractional scaling render incorrectly. The only question what's
the bug: inconsistency in the QT_SCREEN_SCALE_FACTORS behavior or KDE
using wrong way to set the scaling. And the lack of consensus makes
it impossible to fix it on Qt side/report to KDE. :(
As a result, affected applciations are unusable for a long time.
That’s fair point. The QT_ environment variables are often sharp tools, and do make it possible to configure Qt in such a way that it appears broken.
I’m not sure I see what KDE could realistically change here - given that they want to continue to set QT_SCREEN_SCALE_FACTORS, also with fractional factors since that works for most/many apps. Did you have a specific solution in mind?
Continuing on the more pragmatic track, I’ve pushed a change to add rounding support, along with some additional testing: https://codereview.qt-project.org/c/qt/qtbase/+/412296
Morten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220520/5dc939f2/attachment.htm>
More information about the Development
mailing list