GUI scaling rendered KDevelop useless on Windows 10

René J.V. Bertin rjvbertin at gmail.com
Wed Sep 15 10:05:27 BST 2021


On Wednesday September 15 2021 05:43:44 Ingvar Tjøstheim wrote:

>I only use one screen at the same time. I have a USB-C dock for the laptop, where the monitor is plugged in. I either use the monitor through this, or use the built-in laptop monitor when I disconnect the dock.

IMHO that does make the issue a bit less acute I think, or at least I can't imagine you're dis- and re-connecting the laptop to that dock so frequently that quitting KDevelop first is too cumbersome.
It would be interesting to know though if you get the same problem when you go for a multihead configuration (make the external the main screen, keep the laptop screen active) and move the KDevelop window back and forth between the 2 screens.

>I don't have any other KDE or programs. I believe Audacity is Qt, and it is not affected. 

No, Audacity is based on wxWindows. VirtualPC is based on Qt, though, so is Scribus (just to name 2 pro-quality free apps). There are multiple KDE applications available in MSWin builds: Kate (text editor), Dolphin (file explorer, sadly not with the full range of supported remote filesystems) or digiKam (digital photo album). KDevelop development seems a little slow lately (suits me fine! :)), the other cited apps less so as far as I can tell.

Either way, someone will have to figure out if your issue is specific to KDevelop, to KDE (ie. the KF5 frameworks) or if it's a Qt issue. If other KDE apps do exhibit the same issue you could (should...) install the latest Qt 5.1x (5.15.2?) through the official installer. This will give you the QtCreator IDE but also Qt's Assistant (doc reader), allowing to determine if a "pure" and "official" Qt application exhibits the same issue.

If it doesn't in the latest 5.1x version you could even install additional, older versions through the Maintenance Tool, starting with the version used by KDEvelop's build for MSWin (I have no idea what Qt version that is but you can find it via the "About KDevelop" menu action).

>Yesterday I actually unplugged the dock from the computer and due to other Windows 10 issues had to force-restart the computer. The computer appeared to not want to turn on (black screen) until I had held the power button a while. After finally managing to boot the computer with only the laptop screen, KDevelop somehow was restored to normal size.
>If the issue returns, I will try turning the computer off, restarting and cycling power, etc, while paying attention to what works and not. I will let you know.

Wait, are you saying that the issue is NOT resolved by restarting KDevelop? If I understand the above correctly, KDevelop probably told you it didn't exit properly when you first started it again after the reboot, i.e. it "crashed". I have no idea how you can make a program to crash/abort on Win10, but if you can figure that out it would definitely be of interest because it points to the inappropriate use of cached data used for rendering the UI. IMHO that kind of information shouldn't be cached on disk but that's a subject for future discussion!

Did the restart solve the issue completely (for now)? In my experience it's not a bad idea to restart MSWin computers regularly, or even turn them off at the end of the day.

>This is a relatively new Lenovo X1 Carbon Gen 8 laptop.

Does it have dual GPUs, i.e. the one inside the CPU and a dedicated/discrete video adapter? If it does you also have the option of forcing KDevelop to use either one of the two, and see if that makes a difference. If it does that would hint at an issue in the driver for the affected GPU.

You could also just install Linux; the laptop is bound to run better/faster that way ;)

R.


More information about the KDevelop mailing list