RE: GUI scaling rendered KDevelop useless on Windows 10

Dear KDevelop developers

The issue has reappeared where the menu items of KDevelop GUI have been sca=
led up.
This seemed to appear again after windows 10 woke up from sleep and spent a=
bout 1 minute scaling all sorts of windows and GUI components up and down s=
everal times, and while connected to the dock at work.
I have put the computer to sleep without it happening. But this time it did=
.

Putting the computer back to sleep and waking it didn't help.
Restarting KDevelop didn't help.
Disconnecting and reconnecting the dock didn't help.
Switching between monitors didn't help.
Restarting the computer didn't help.

Shutting down and booting up again fixed the problem (until next time...)

Hurray for anyone who do not use Windows.

-Ingvar



-----Original Message-----
From: Ingvar Tj=F8stheim=20
Sent: 17 September 2021 08:32
To: Ren=E9 J.V. Bertin <[email protected]>
Cc: [email protected]
Subject: RE: GUI scaling rendered KDevelop useless on Windows 10

Thanks for this useful information.

This has only happened this one (aggregated) time.

If, or when it happens again, I will try to think of what reproduces it, an=
d now have more ideas on hand on how to troubleshoot.

I will try to get back to you all with updates if I have any.

Thank you!

-Ingvar

-----Original Message-----
From: Ren=E9 J.V. Bertin <[email protected]>=20
Sent: 16 September 2021 10:49
To: Ingvar Tj=F8stheim <[email protected]>
Cc: [email protected]
Subject: Re: GUI scaling rendered KDevelop useless on Windows 10

Ingvar Tj=F8stheim wrote on 20210916::05:53:04 re: "RE: GUI scaling rendere=
d KDevelop useless on Windows 10"

(bouncing this back to the list)

>As KDevelop GUI scaling had enlarged before I got here, it remained this w=
ay as I connected here and switched monitors. I do not know if it worsened,=
 but it has not reappeared yet.

Do you mean the issue is back already? How do you handle the suspend/commut=
e/wake cycle? Do you disconnect the one dock before you suspend the compute=
r and connect the other after you wake the computer? That seems the safer r=
oute . I used to do the opposite with the external screens on my Mac (not v=
ia a dock) and that went fine with older (=3D graphically simpler) versions=
 of the OS until it no longer did.

>I will try to find out whether it is easier to reproduce at home, as I hav=
e not been able to do so here.
>When switching between monitors here, Windows 10 does scale all GUI, so I =
would think the problem could appear here too.

You say the monitor at work has a lower resolution, is it maybe one that wo=
uldn't qualify as a "high dpi" screen?

Here's what Qt wants us to know about DPI scaling (have fun!) :
https://doc.qt.io/qt-5/highdpi.html

From there, things you can try when the issue returns:
- start KDevelop with a specific `dpiawareness`
- start KDevelop with one of QT_AUTO_SCREEN_SCALE_FACTOR/QT_SCALE_FACTOR/QT=
_SCREEN_SCALE_FACTORS set in the MSWin environment
- start KDevelop using the Fusion style (the "native" MSWin style apparentl=
y has some issues with highdpi scaling).

Points 1 and 3 can be done via a qt.conf file (I think in the directory whe=
re KDevelop is installed; see https://doc.qt.io/qt-5/qt-conf.html), environ=
ment variables (like QT_SCREEN_SCALE_FACTORS) would apply to all Qt applica=
tions.

NB: that doc does state that monitors can have incorrect EDID information -=
 but I think you'd be seeing the issue all the time if that were the case .=
.. although that's also the kind of information that *might* be cached by a=
n OS and become corrupted, esp. when you're swapping external displays regu=
larly.

R.