fix: 150% and 200% zoom levels prevent the user from logging in #13689
Conversation
Jenkins BuildsClick to see older builds (6)
|
|
This is awesome. I just tested and it works perfect for me. 150% used to be disgustingly too big, but now it's pretty decent on my high def monitor. Thanks! |
caybro
force-pushed
the
13484-150-and-200-zoom-levels-prevent-the-user-from-logging-in
branch
from
4276b93
to
2bb65c0
Compare
caybro
requested review from
alexjba,
alexandraB99,
jrainville and
Michal-Status
Great to hear! Can you pls give it a quick try on Windows as well, if you can? :) |
Yeah I'm doing that but now I realized I should rather do it with the |
|
@jrainville pretty pls 🙏 |
There was a problem hiding this comment.
200% zoom level does not prevent from logging in on the resolution the bug was initially reported on. Switching zooms in 25% increments works well for all of the zoom levels implemented. However the issue still occurs on higher zoom levels. Combining higher zoom levels (especially newly implemented 300%) with a lower screen resolution and size causes similar issues as the original one.
- TLDR: we were scaling twice, resulting in ginourmous pixel values The long story: - since Qt treats the various scale factors in a multiplicative way (see https://www.qt.io/blog/2016/01/26/high-dpi-support-in-qt-5-6 for explanation) and there's no way to get the screen's baseline scale factor programatically, we also have to export `QT_SCREEN_SCALE_FACTORS` to something that's not equal to `0` or `1` to force the monitor scale factor to `100%` and then compensate for it when exporting our own scale value using `QT_SCALE_FACTOR` - make the UI slider values go in `25%` steps, allowing for more fine grained control; with `100%` we fallback to the Qt's native handling of highdpi - raised the maximum to `300%` since on highres displays, one wouldn't be able to go over the implicit maximum of `200%` (due to the internal scaling being 2x) - scale our main window's minimum width/height so that we don't overflow the monitor's available space - modernize the `ConfirmAppRestartModal` to use `StatusDialog` - use the new `Utils.restartApplication()` when changing the UI language as well - remove some dead code In the (very) long term, we should take a different approach of scaling our app independently of Qt, just taking the monitor `Screen.devicePixelRatio` into account, similar to what other apps like Telegram do Fixes #13484
caybro
force-pushed
the
13484-150-and-200-zoom-levels-prevent-the-user-from-logging-in
branch
from
2bb65c0
to
5f3ec5f
Compare
caybro
deleted the
13484-150-and-200-zoom-levels-prevent-the-user-from-logging-in
branch
What does the PR do
The long story:
QT_SCREEN_SCALE_FACTORSto something that's not equal to0or1to force the monitor scale factor to100%and then compensate for it when exporting our own scalevalue using
QT_SCALE_FACTOR25%steps, allowing for more fine grained control; with100%we fallback to the Qt's native handling of highdpi300%since on highres displays, one wouldn't be able to go over the implicit maximum of200%(due to the internal scaling being 2x)ConfirmAppRestartModalto useStatusDialogUtils.restartApplication()when changing the UI language as wellIn the (very) long term, we should take a different approach of scaling our app independently of Qt, just taking the monitor
Screen.devicePixelRatiointo account, similar to what other apps like Telegram doFixes #13484
Affected areas
AppearanceView
Screenshot of functionality (including design for comparison)
Zaznam.obrazovky.z.2024-02-23.09-34-50.webm