| Summary: | digikam 8.4.0 ignores KDE font settings and scale factor. | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Vadym Krevs <vkrevs> |
| Component: | Usability-Ergonomy | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, freddie, metzpinguin, vkrevs |
| Priority: | NOR | ||
| Version First Reported In: | 8.4.0 | ||
| Target Milestone: | --- | ||
| Platform: | OpenBSD | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/graphics/digikam/-/commit/e0934167e5cf8847d423ad402f2d137c9e9be526 | Version Fixed In: | 8.5.0 |
| Sentry Crash Report: | |||
| Attachments: |
digikam fonts and kde font config, other kde apps
Screenshot showing the issue. |
||
|
Description
Vadym Krevs
2024-07-26 19:43:24 UTC
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 |