make the app correctly evaluate QT_AUTO_SCREEN_SCALE_FACTOR
Danfro opened this issue · comments
Currently with Ubuntu Touch development it was considered "the way to go" to use QT_AUTO_SCREEN_SCALE_FACTOR. But some apps, like nymea, seem to not cover all three possible states of this value which results in scaling issues e.g. the whole UI being really tiny.
For OTA2 focal those changes have been reverted, but it will be back after that.
So ideally by that time all apps can evaluate the following three possible states of this variable:
- QT_AUTO_SCREEN_SCALE_FACTOR=1
- QT_AUTO_SCREEN_SCALE_FACTOR=0
- QT_AUTO_SCREEN_SCALE_FACTOR is not set at all
This seem to be "useful"/needed for apps being run under various scenarios once Lomiri is upstream.
For reference also see: https://gitlab.com/groups/ubports/development/core/-/epics/39
From what I understand the Qt highdpi scaling mechanism is to be enabled. nymea-app already does this here: https://github.com/nymea/nymea-app/blob/master/nymea-app/main.cpp#L74
Is it not working properly?
I had nymea in tiny size mode when they where playing around with the scale factor setting. I am afraid, I don't know exactly what was done when I had this. On my Xperia X I had 6 things in one row, where normally only two fit there.
I'm afraid we'd need more info on this one. Ideally a system where we can test this. Right now I am really not sure what to do. As I said, the general Qt HighDPI handling is already enabled (as it's also used on android) and if I start it here with different settings of QT_AUTO_SCREEN_SCALE_FACTOR it does seem to do the expected things.
Because the changes have been reverted so they do not block OTA2, I can't do some testing right now. After OTA2 focal (expected at the end of June), it will be reimplemented at some point. So I guess we need to leave this as it is for now.