Bug 457272

Created attachment 150978 [details]
Krita side by side with digiKam

I think Krita uses a 0 padding. We put this padding on purpose I find the layout too "tight" on Krita. Certainly Krita wants to display more GUI elements.

Maik

(In reply to Maik Qualmann from comment #2)
> I think Krita uses a 0 padding. We put this padding on purpose I find the
> layout too "tight" on Krita. Certainly Krita wants to display more GUI
> elements.

I just picked Krita as a representative application.  It's padding is the same as Kate, Kwrite, Dolphin, System Monitor, ParaView, Lyx, Konsole, ... digiKam, however, appears to have awkward tighter padding on high-DPI systems (I do not recall seeing this tightness on standard DPI without scaling).

Look at the Kate session selection between the search input and the list view the same distance as in digiKam, in Kate itself again a 0 padding. As I said, it is our intention. I used to play in digiKam with a 0 padding a long time ago, but I didn't like it because the sidebar elements are closer to the thumbnails and previews. That looked "more confusing". Maybe we could reduce the top and bottom padding, I could test that again. Basically we use the padding recommended by Qt.

Maik

Just to avoid any misunderstanding, are you talking about the border padding or the item margin (left, top, right, bottom)?

Maik

(In reply to Maik Qualmann from comment #5)
> Just to avoid any misunderstanding, are you talking about the border padding
> or the item margin (left, top, right, bottom)?

The overall widget padding.  Consider the menu bar.  Counting the pixels in Krita between the right hand side of the "t" in "Edit" and the left hand side of the "V" in view we get 31px.  But in digiKam it is 20.  Now lets look at tab height.  In Krita our tabs are 45px high, whilst in digiKam they are 36px.  Things get more fun if we look at the base-line distance: 10px in digiKam and 15px in Krita.

Curiously, these ratios are, give or take a pixel, those of my high-DPI scale factor (1.5x).

Created attachment 150985 [details]
padding.png

Here is a screenshot, at 1.5 scaling, comparing Edit and View. Tested with native digiKam-8.0.0 on openSUSE Tumbleweed. Absolutely identical. What digiKam version are you using, on which system?

Maik

(In reply to Maik Qualmann from comment #7)
> Created attachment 150985 [details]
> padding.png
> 
> Here is a screenshot, at 1.5 scaling, comparing Edit and View. Tested with
> native digiKam-8.0.0 on openSUSE Tumbleweed. Absolutely identical. What
> digiKam version are you using, on which system?

Version 7.5.0 with KDE Frameworks 5.96.0 and Qt 5.15.5 and the xcb windowing system.  All packages from Gentoo portage.  (I am still waiting for my distro to bump to 7.7.0 as per https://bugs.gentoo.org/861341).

(In reply to Freddie Witherden from comment #8)
> Version 7.5.0 with KDE Frameworks 5.96.0 and Qt 5.15.5 and the xcb windowing
> system.  All packages from Gentoo portage.  (I am still waiting for my
> distro to bump to 7.7.0 as per https://bugs.gentoo.org/861341).
7.8.0 is available in ~arch for you to test.

(In reply to Andreas Sturmlechner from comment #9)
> (In reply to Freddie Witherden from comment #8)
> > Version 7.5.0 with KDE Frameworks 5.96.0 and Qt 5.15.5 and the xcb windowing
> > system.  All packages from Gentoo portage.  (I am still waiting for my
> > distro to bump to 7.7.0 as per https://bugs.gentoo.org/861341).
> 7.8.0 is available in ~arch for you to test.

Confirmed that the spacing is unchanged with 7.8 (still too tight compared with other KDE and Qt applications).

Freddie,

digiKam 8.0.0 is out. This entry still valid with this release ?

Best regards

Gilles Caulier

(In reply to caulier.gilles from comment #11)
> digiKam 8.0.0 is out. This entry still valid with this release ?

Still waiting for Gentoo to update their packages.  However, it is still present on 7.10 (latest version they have packaged).  Will let you know as soon as they've upgraded to 8.

Freddie,

The Linux AppImage 8.1.0 pre-release includes Breeze Widget style module which will improve certainly the way to render widget in digiKam.

Please test with the bundle available here :

https://files.kde.org/digikam/

How to run digiKam AppImage :

https://docs.digikam.org/en/getting_started/installation.html#digikam-on-linux

The Breeze widget style must be selected in Setup/Misc/Appearence tab : 

https://docs.digikam.org/en/setup_application/miscs_settings.html#appearance-settings

Best

Gilles Caulier

(In reply to caulier.gilles from comment #13)
> Freddie,
> 
> The Linux AppImage 8.1.0 pre-release includes Breeze Widget style module
> which will improve certainly the way to render widget in digiKam.
> 
> Please test with the bundle available here :
> 
> https://files.kde.org/digikam/
> 
> How to run digiKam AppImage :
> 
> https://docs.digikam.org/en/getting_started/installation.html#digikam-on-
> linux
> 
> The Breeze widget style must be selected in Setup/Misc/Appearence tab : 
> 
> https://docs.digikam.org/en/setup_application/miscs_settings.html#appearance-
> settings
> 
> Best
> 
> Gilles Caulier

My distribution (Gentoo) has recently updated to 8.1.  Please find a screenshot attached which shows the the layout is still too cramped (count the number of pixels between "Settings" and "Help" in digiKam vs System Monitor.  I can confirm that the Breeze widget style is set in the settings.

Created attachment 160324 [details]
Bug reproduction with 8.1

Checked again with the system monitor and digiKam-8.2.0, here under openSUSE the distances between Settings and Help are identical. To be honest, our code doesn't affect these distances anywhere either. If so, your problem must be related to the KF5 Framework.

Maik

Did you see the option to scale to the screen factor in the digiKam settings under Miscellaneous-> System?
Depending on whether you use a scaling factor (you probably use 1.5) you have to activate/deactivate this option.

Maik

(In reply to Maik Qualmann from comment #17)
> Did you see the option to scale to the screen factor in the digiKam settings
> under Miscellaneous-> System?
> Depending on whether you use a scaling factor (you probably use 1.5) you
> have to activate/deactivate this option.

I can confirm that ticking this resolve the issue (along with high resolution pixmaps to get everything cleaned up after).  However, why is this option needed/not the default?  All other Qt applications (and others like LibreOffice, Firefox, and Chrome) seem to pick it up fine from the system's environmental variables.

digiKam is present on different operating systems. High-resolution pixmaps have long time led to broken icons on macOS. Many Windows users use a scaling factor, but the digiKam GUI is too big for some, etc. Therefore, these options can be changed in digiKam. As of Qt6, these options will be omitted anyway, since they are generally active and can no longer be deactivated.

Maik

Defaults can vary between Operating Systems.

Git commit 35e5817353709c5c16521fee116bb3c70196aa0f by Maik Qualmann.
Committed on 18/07/2023 at 16:31.
Pushed by mqualmann into branch 'master'.

for a new config under Linux scaling and high-resolution icons are enabled
FIXED-IN: 8.2.0

M  +1    -1    NEWS
M  +12   -0    core/utilities/setup/misc/systemsettings.cpp

https://invent.kde.org/graphics/digikam/-/commit/35e5817353709c5c16521fee116bb3c70196aa0f