Bug 398056 - Icons are too small (4k resolution display)
Summary: Icons are too small (4k resolution display)
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: UI: general (show other bugs)
Version: 5.2.3
Platform: Microsoft Windows Microsoft Windows
: NOR grave
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-30 09:12 UTC by Saverio
Modified: 2018-09-08 02:49 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.2.80


Attachments
the screen of kdevelop (174.60 KB, image/png)
2018-08-30 11:22 UTC, Saverio
Details
Screen of KDevelop, NOW IT WORKS! (484.61 KB, image/png)
2018-08-31 09:00 UTC, Saverio
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Saverio 2018-08-30 09:12:45 UTC
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)
Comment 1 Kevin Funk 2018-08-30 11:13:42 UTC
Please attach a screenshot.
Comment 2 Saverio 2018-08-30 11:22:37 UTC
Created attachment 114701 [details]
the screen of kdevelop
Comment 3 Kevin Funk 2018-08-30 11:50:27 UTC
Thanks!
Comment 4 Christoph Feck 2018-08-30 13:49:14 UTC
Is this issue also solved with the fix for bug 398055?
Comment 5 Saverio 2018-08-30 15:56:32 UTC
That issue was open from me too.
No, KDevelop is still wrong because I haven't found in the Settings the "hidpi"
Comment 6 Friedrich W. H. Kossebau 2018-08-30 16:03:30 UTC
The Krita setting results in the call of
QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

We could that unconditionally in KDevelop possibly.
Comment 7 Saverio 2018-08-30 16:05:40 UTC
I don't find that option in KDevelop Settings. Could you send me a screen please?
Comment 8 Friedrich W. H. Kossebau 2018-08-30 16:12:13 UTC
(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.
Comment 9 Saverio 2018-08-30 16:13:38 UTC
Oh, ok. Sorry, I didn't understand xD
So, I'll wait other possible solutions, thanks anyway :)
Comment 10 Kevin Funk 2018-08-30 19:53:18 UTC
@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...
Comment 11 Friedrich W. H. Kossebau 2018-08-30 21:21:05 UTC
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
Comment 12 Nate Graham 2018-08-30 21:30:57 UTC
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. :)
Comment 13 Christoph Feck 2018-08-30 22:44:02 UTC
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.
Comment 14 Kevin Funk 2018-08-30 22:47:34 UTC
@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!
Comment 15 Friedrich W. H. Kossebau 2018-08-30 23:51:59 UTC
(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 :)
Comment 16 Friedrich W. H. Kossebau 2018-08-31 00:05:46 UTC
(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);
[...]
Comment 17 Saverio 2018-08-31 08:51:12 UTC
I've just installed the new version and I am happy to say to you IT WORKS CORRECTLY NOW! Thank you very much guys! :)
Comment 18 Friedrich W. H. Kossebau 2018-08-31 08:55:28 UTC
(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)
Comment 19 Fabian Vogt 2018-08-31 08:58:21 UTC
(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 :)
Comment 20 Saverio 2018-08-31 09:00:42 UTC
Created attachment 114715 [details]
Screen of KDevelop, NOW IT WORKS!

"Et voilà"
Comment 21 Friedrich W. H. Kossebau 2018-08-31 09:22:17 UTC
(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.
Comment 22 Saverio 2018-08-31 10:12:34 UTC
(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 :)
Comment 23 Andrew Crouthamel 2018-09-08 02:42:49 UTC
(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?
Comment 24 Andrew Crouthamel 2018-09-08 02:49:06 UTC
(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?