630da7caaa
- 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 |
||
|---|---|---|
| .. | ||
| StatusQ | ||
| app | ||
| fonts | ||
| i18n | ||
| imports | ||
| include/StatusDesktop/Monitoring | ||
| src/StatusDesktop/Monitoring | ||
| MonitoringSources.cmake | ||
| generate-rcc.go | ||
| main.qml | ||
| nim-status-client.pro | ||