KDevelop on my pc (hp spectre 13-af005nl) doesn't work correctly. Actually the problem is "ICONS TOO SMALL" and I can't work with this software. The resolution of my display is 4K (3840x2169)
Please attach a screenshot.
Created attachment 114701 [details] the screen of kdevelop
Thanks!
Is this issue also solved with the fix for bug 398055?
That issue was open from me too. No, KDevelop is still wrong because I haven't found in the Settings the "hidpi"
The Krita setting results in the call of QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling); We could that unconditionally in KDevelop possibly.
I don't find that option in KDevelop Settings. Could you send me a screen please?
(In reply to Saverio from comment #7) > I don't find that option in KDevelop Settings. Could you send me a screen > please? You cannot find it because there is no such setting in the KDevelop UI :) Krita has special code to support enabling/disabling that Qt::AA_EnableHighDpiScaling flag internally, together with special UI code for it. Not owning a hidpi screen myself and no experience. Reading http://doc.qt.io/qt-5/highdpi.html makes me assume that setting Qt::AA_EnableHighDpiScaling is the way to go now, to support such output devices. But needs someone to confirm.
Oh, ok. Sorry, I didn't understand xD So, I'll wait other possible solutions, thanks anyway :)
@frinring: Go for it. I thought since some Qt version that was implicitly set; but apparently I was wrong. I see tons of other KDE applications (specifically kdepim ones) setting that attribute as well...
Git commit f909038352e0c6b8e9fa05570d261b03fa4e9369 by Friedrich W. H. Kossebau. Committed on 30/08/2018 at 20:58. Pushed by kossebau into branch '5.3'. kdevelop app: set Qt::AA_EnableHighDpiScaling FIXED-IN: 5.2.80 M +3 -0 app/main.cpp https://commits.kde.org/kdevelop/f909038352e0c6b8e9fa05570d261b03fa4e9369
Wow, that was fast. If someone sends me a satisfactory picture of KDevelop with this fix applied, I'll include it with this week's Usability & Productivity post. :)
What exactly is the difference between Qt::AA_UseHighDpiPixmaps and Qt::AA_EnableHighDpiScaling, and should both be enabled for proper HiDPI support? Most applications I see only set the former property.
@Saverio: It would be great if you could try the newly generated Windows installer which should have the fix for this issue: https://binary-factory.kde.org/job/KDevelop_Nightly_win64 (download the .exe) Please report back!
(In reply to Christoph Feck from comment #13) > What exactly is the difference between Qt::AA_UseHighDpiPixmaps and > Qt::AA_EnableHighDpiScaling, and should both be enabled for proper HiDPI > support? Most applications I see only set the former property. Good question. Not exactly sure, but I would bet both should be set for really good looking UI currently for our legacy-based applications like KDevelop, which rely on code done around low-dpi pixel sizes (think icon sizes referring to 16, 32 or 64 pixels per dimension), as still relied on in all(?) the QtWidget-based KDE Frameworks modules. From what I understood by reading the docs, Qt::AA_EnableHighDpiScaling cares for scaling any QPainter commands and other pixel-based geometries. While Qt::AA_UseHighDpiPixmaps makes sure that pixmaps which are rendered for the unscaled pixel sizes are internally prepared for the real pixels sizes when rendered in the end onto the real display. But we indeed should consult some experts, not putting my hand here close to any fire. (Adding fvogt as potential expoert to cc: list) Fabian, can you tell more? (In reply to Saverio from comment #9) > Oh, ok. Sorry, I didn't understand xD > So, I'll wait other possible solutions, thanks anyway :) Saverio, as Kevin asked and linked, please test the Nigthly build of the Windows version created after my commit. My fix was done as blind fix, just done based on documentation and given it did not break things for me on my lowdpi system :)
(In reply to Friedrich W. H. Kossebau from comment #15) > (In reply to Christoph Feck from comment #13) > > What exactly is the difference between Qt::AA_UseHighDpiPixmaps and > > Qt::AA_EnableHighDpiScaling, and should both be enabled for proper HiDPI > > support? Most applications I see only set the former property. > > Good question. > Not exactly sure, but I would bet both should be set for really good looking > UI currently for our legacy-based applications like KDevelop Qt code examples seem to do that as well, e.g. http://doc.qt.io/qt-5/qtwidgets-mainwindows-mainwindow-main-cpp.html int main(int argc, char **argv) { QApplication::setAttribute(Qt::AA_EnableHighDpiScaling); QApplication::setAttribute(Qt::AA_UseHighDpiPixmaps); QApplication app(argc, argv); [...]
I've just installed the new version and I am happy to say to you IT WORKS CORRECTLY NOW! Thank you very much guys! :)
(In reply to Saverio from comment #17) > I've just installed the new version and I am happy to say to you IT WORKS > CORRECTLY NOW! Thank you very much guys! :) Good news, thanks for telling :) Any chance you could give us a sample screenshot? And are the icons all crisp as well? (Those which have curvy parts would be the interesting here, as they would show artifacts)
(In reply to Friedrich W. H. Kossebau from comment #15) > (In reply to Christoph Feck from comment #13) > > What exactly is the difference between Qt::AA_UseHighDpiPixmaps and > > Qt::AA_EnableHighDpiScaling, and should both be enabled for proper HiDPI > > support? Most applications I see only set the former property. > > Good question. > Not exactly sure, but I would bet both should be set for really good looking > UI currently for our legacy-based applications like KDevelop, which rely on > code done around low-dpi pixel sizes (think icon sizes referring to 16, 32 > or 64 pixels per dimension), as still relied on in all(?) the QtWidget-based > KDE Frameworks modules. > From what I understood by reading the docs, Qt::AA_EnableHighDpiScaling > cares for scaling any QPainter commands and other pixel-based geometries. > While Qt::AA_UseHighDpiPixmaps makes sure that pixmaps which are rendered > for the unscaled pixel sizes are internally prepared for the real pixels > sizes when rendered in the end onto the real display. > But we indeed should consult some experts, not putting my hand here close to > any fire. > > (Adding fvogt as potential expoert to cc: list) > Fabian, can you tell more? It's complicated. QPainter etc. scale all the time, but by default the devicePixelRatio is 1 so it has no effect (except on OS X). All AA_EnableHighDpiScaling does is set the devicePixelRatio according to the DPI of the monitor the application is on. On Plasma on X11, where AA_EnableHighDpiScaling has no effect at all as it's overwritten using environment variables (QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS). AA_UseHighDpiPixmaps is important as it allows QPixmap with a devicePixelRatio of > 1. So your guess is correct, both is the best option here. > (In reply to Saverio from comment #9) > > Oh, ok. Sorry, I didn't understand xD > > So, I'll wait other possible solutions, thanks anyway :) > > Saverio, as Kevin asked and linked, please test the Nigthly build of the > Windows version created after my commit. My fix was done as blind fix, just > done based on documentation and given it did not break things for me on my > lowdpi system :)
Created attachment 114715 [details] Screen of KDevelop, NOW IT WORKS! "Et voilà"
(In reply to Saverio from comment #20) > Created attachment 114715 [details] > Screen of KDevelop, NOW IT WORKS! > > "Et voilà" Thanks. Yes, looking good :) (though we might need to improve blurry background logo and some spacing in the buttons of the welcome page). Ah, given Nate asked, are you okay with him using it in his personal Usability & Productivity blog posts, as appearing on planet KDE? Should be fine given no personal data in it.
(In reply to Friedrich W. H. Kossebau from comment #21) > (In reply to Saverio from comment #20) > > Created attachment 114715 [details] > > Screen of KDevelop, NOW IT WORKS! > > > > "Et voilà" > > Thanks. Yes, looking good :) (though we might need to improve blurry > background logo and some spacing in the buttons of the welcome page). > > Ah, given Nate asked, are you okay with him using it in his personal > Usability & Productivity blog posts, as appearing on planet KDE? Should be > fine given no personal data in it. Yes, logo and some (few) things. But now, at least, we can work also on 4K display :)
(In reply to Fabian Vogt from comment #19) > (In reply to Friedrich W. H. Kossebau from comment #15) > > (In reply to Christoph Feck from comment #13) > > > What exactly is the difference between Qt::AA_UseHighDpiPixmaps and > > > Qt::AA_EnableHighDpiScaling, and should both be enabled for proper HiDPI > > > support? Most applications I see only set the former property. > > > > Good question. > > Not exactly sure, but I would bet both should be set for really good looking > > UI currently for our legacy-based applications like KDevelop, which rely on > > code done around low-dpi pixel sizes (think icon sizes referring to 16, 32 > > or 64 pixels per dimension), as still relied on in all(?) the QtWidget-based > > KDE Frameworks modules. > > From what I understood by reading the docs, Qt::AA_EnableHighDpiScaling > > cares for scaling any QPainter commands and other pixel-based geometries. > > While Qt::AA_UseHighDpiPixmaps makes sure that pixmaps which are rendered > > for the unscaled pixel sizes are internally prepared for the real pixels > > sizes when rendered in the end onto the real display. > > But we indeed should consult some experts, not putting my hand here close to > > any fire. > > > > (Adding fvogt as potential expoert to cc: list) > > Fabian, can you tell more? > > It's complicated. > > QPainter etc. scale all the time, but by default the devicePixelRatio is 1 so > it has no effect (except on OS X). All AA_EnableHighDpiScaling does is set > the > devicePixelRatio according to the DPI of the monitor the application is on. > > On Plasma on X11, where AA_EnableHighDpiScaling has no effect at all as it's > overwritten using environment variables (QT_AUTO_SCREEN_SCALE_FACTOR and > QT_SCREEN_SCALE_FACTORS). > > AA_UseHighDpiPixmaps is important as it allows QPixmap with a > devicePixelRatio > of > 1. > > So your guess is correct, both is the best option here. > > > (In reply to Saverio from comment #9) > > > Oh, ok. Sorry, I didn't understand xD > > > So, I'll wait other possible solutions, thanks anyway :) > > > > Saverio, as Kevin asked and linked, please test the Nigthly build of the > > Windows version created after my commit. My fix was done as blind fix, just > > done based on documentation and given it did not break things for me on my > > lowdpi system :) Should we start submitting patches to include both lines on all apps? Or is there a list of "legacy" apps I could tackle?