Created attachment 172016 [details] digikam fonts and kde font config, other kde apps *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY digikam 8.4.0 ignores KDE font settings and scale factor. STEPS TO REPRODUCE 1. Install openSUSE 15.6 on a machine with a hidpi monitor (3840x2160). 2. Set up fonts and 125% global scale factor as per attached screenshot. Log off, log back in. Check scale factors from Konsole: $ echo $QT_SCALE_FACTOR $ echo $QT_SCREEN_SCALE_FACTORS DP-0=1.25;DP-1=1.25;DP-2=1.25;DP-3=1.25;HDMI-0=1.25;DP-4=1.25;DP-5=1.25; 3. Update to latest digikam 8.4.0 from the KDE:Extra repo for openSUSE 15.6 4. Tick "Use high DPI scaling from screen factor" and "Use pixmaps with high DPI resolution", restart digikam. OBSERVED RESULT Digikam's menu fonts are too small, squished and not the same as the configured KDE defaults. Fonts in the Albums tree control are tiny and barely visible EXPECTED RESULT Digikam's menu fonts are the same as the configured KDE defaults. Fonts in the Albums tree control have a sensible size. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: openSUSE 15.6 for x86_64, (available in About System) KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 Graphics platform: X11 ADDITIONAL INFORMATION
digiKam has its own font settings in the digiKam settings under View (for tree view) and in Miscellaneous->Appearance for system fonts. This behavior is intended, we are not only available under KDE, but also on macOS or Windows. The behavior improves when digiKam is compiled with Qt6 and KF6, things like scaling and high-resolution pixmaps are then standard. Here under openSUSE Tumbleweed (Qt6) the fonts are adopted automatically if the digiKam fonts are set to "System Fonts". Maik
(In reply to Maik Qualmann from comment #1) > digiKam has its own font settings in the digiKam settings under View (for > tree view) and in Miscellaneous->Appearance for system fonts. This behavior > is intended, we are not only available under KDE, but also on macOS or > Windows. > > The behavior improves when digiKam is compiled with Qt6 and KF6, things like > scaling and high-resolution pixmaps are then standard. My experience is the opposite here. Under X11 with a 1.5x scale factor everything looks reasonable under Qt5 in terms of fonts and UI spacing (only issue is some low resolution pixmaps). But, switching to Qt6 and everything becomes cramped and icons etc are all smaller than they should be. Other KDE applications using Qt6 (Dolphin, Kate, Krita, ...) are fine and adopt the correct spacing so this is likely digikam overriding some default setting.
The question is which Qt6 combination (AppImage?) you are using exactly under which desktop. Here under a native Qt6/KF6 desktop with native digiKam in Qt6, digiKam looks just like Dolphin or other KF6 programs. Maik
(In reply to Maik Qualmann from comment #3) > The question is which Qt6 combination (AppImage?) you are using exactly > under which desktop. > Here under a native Qt6/KF6 desktop with native digiKam in Qt6, digiKam > looks just like Dolphin or other KF6 programs. Native Qt6/KF6/X11/1.5x scale factor and compiled from source. Screenshot attached with Dolphin for reference (where the scaling is correct and the same as I get when digikam is compiled against Qt5).
Created attachment 172379 [details] Screenshot showing the issue.
Hmm ok, I see the different text spacing. But text size is the same. I have no idea what is causing it at the moment. We are not doing anything different than Gwenview or Dolphin. Maik
(In reply to Maik Qualmann from comment #6) > Hmm ok, I see the different text spacing. But text size is the same. I have > no idea what is causing it at the moment. We are not doing anything > different than Gwenview or Dolphin. That's what they all say ;) In digikam we have in main.cpp: QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::RoundPreferFloor); which breaks fractional scaling since 1.5 => 1 which gives the incorrect spacing. This is not a line you'll find in Dolphin. Thankfully, Qt lets us override this with an environment variable back to the default. Running: QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough digikam and life is (mostly) good again. It is certainly not a panacea; rendering code which is not prepared for fractional scale factors is likely to show issues (and this appears to be why the line was introduced in the first place).
OK, the option is the cause. If I remember correctly, it is also used by Krita. The reason was Bug 478525. Maik
(In reply to Maik Qualmann from comment #8) > OK, the option is the cause. If I remember correctly, it is also used by > Krita. The reason was Bug 478525. Krita are currently Qt5 where this option does not appear to cause issues (same with digikam under Qt5). My suggestion would be to not set this option when running under Qt6 and if the jumping bug is still present to audit the rendering code.
Git commit e0934167e5cf8847d423ad402f2d137c9e9be526 by Maik Qualmann. Committed on 09/08/2024 at 21:04. Pushed by mqualmann into branch 'master'. remove high dpi scale factor rounding policy and optimize QGraphicsItem render position FIXED-IN: 8.5.0 M +2 -2 NEWS M +0 -2 core/app/main/main.cpp M +26 -15 core/libs/widgets/graphicsview/graphicsdimgitem.cpp M +0 -2 core/showfoto/main/main.cpp M +23 -15 core/utilities/imageeditor/widgets/imagepreviewitem.cpp M +1 -1 core/utilities/imageeditor/widgets/imageregionitem.cpp https://invent.kde.org/graphics/digikam/-/commit/e0934167e5cf8847d423ad402f2d137c9e9be526