Tested with live iso neon5-201408080914 Cause: Invalid edid information from samsung syncmaster using hdmi (160x90) No effect using xorg.conf monitor section with DisplaySize 520 290 or xsession.d with xrandr -fbmm 520x290;xrandr --dpi 94x94 session-errors: http://paste.kde.org/pgu7yzwi7 Xorg.0.log: http://paste.kde.org/pmg17uyxb
*** Bug 338183 has been marked as a duplicate of this bug. ***
Created attachment 88358 [details] Xorg.0.log with fixed display dimension
xrandr output: Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 VGA-0 disconnected (normal left inverted right x axis y axis) HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 160mm x 90mm 1920x1080 60.0*+ 50.0 59.9 1920x1080i 60.1 50.0 60.0 1600x1200 60.0 1680x1050 59.9 1280x1024 60.0 1440x900 59.9 1280x960 60.0 1280x800 59.9 1280x720 60.0 50.0 59.9 1024x768 60.0 800x600 60.3 56.2 720x576 50.0 720x480 60.0 59.9 640x480 60.0 59.9
Created attachment 88377 [details] Output of xrandr -q
I'm having this problem as well as other incorect scaling of plasma elements (like the screen corner glow size (https://bugs.kde.org/show_bug.cgi?id=337712)). Icon is the correct size in project neon on a virtualpc, but is in error on my laptop running arch. Still having this problem on a build from source a few days old.
*** Bug 335510 has been marked as a duplicate of this bug. ***
Assigning to Plasma Frameworks as it's the Units that's "wrong". Marco, can we just use the user configured Icon sizes (KIconLoader::IconSize) rather than scaling numbers by DPI ourselves. It clearly isn't working that well currently as this problem has had 3 reports already.
Using the settings from the user can still be done, and will take effect, but the DPI scaling will be intact, so it's not breaking that feature. Ignoring DPI will mean that we lose all the HiDPI goodness we introduced with exactly this scaling algorithm -- a huge step back for many users. I really do not want to lose this feature, but I'm open to think about different ways. With the DPI features in Qt 5.4, we can perhaps do better? Just removing it is not an option to me, sorry, as it introduces regressions for everybody on a slightly better than normal display, and it will simply make many things unusable for those with real high DPI displays.
"With the DPI features in Qt 5.4, we can perhaps do better?" iirc the highdpi branch didn't make it for 5.4, so is still a future problem. but yes, our dpi calculations should remain, at least until qt will have that too. (on the other hand, imo the sizes categories from kiconlaoder like desktop,panel,toolbar etc, should be dprecated as in conceptually obsolete, or at least new more meaningful categories should be introduced)
If the user doesn't change their icon settings all apps will look broken anyway, so it must be safe to assume they're correct... and if it's not we need to fix it anyway?
Thought a bit more about it ... we could use the same ratios as for units.gridUnit, since that is almost guaranteed to match with the surrounding UI (and the user can influence it together with font settings). The bugreports I looked at should be fine with such a solution. Thoughts?
So scale according to how much the font differs from the default font size (12px?) I'd still prefer using the user set values, but I'd be happy enough with this approach, it would fix all of these bugs.
No, scaling with the pixelsize of the fonts as the user configured them. That takes DPI and user settings into account and makes it the same as gridUnit (which forms the basis of all the other ui sizing).
Proposed patch: https://git.reviewboard.kde.org/r/119983/
*** Bug 341145 has been marked as a duplicate of this bug. ***
*** Bug 341858 has been marked as a duplicate of this bug. ***
Git commit 1ce575cf5a3b2e37d54a47340396b2b9fd8cfa41 by David Edmundson. Committed on 04/03/2015 at 09:14. Pushed by davidedmundson into branch 'master'. Simple fix for huge icon sizes Currently units is based on font metrics except icon size and some SVG parts which use DPI directly. Instead of taking the physical DPI we take the logical DPI which is used for working out font point -> pixel sizes. We can rely on this being correct as otherwise every other app would appear broken. REVIEW: 122799 Change-Id: I22f668ccea7d6d15ff475e1368c82964bdde1e60 M +1 -1 src/declarativeimports/core/units.cpp http://commits.kde.org/plasma-framework/1ce575cf5a3b2e37d54a47340396b2b9fd8cfa41