Bug 493687

Summary: No longer adjusting GridUnit by the font size makes many layouts using it for hardcoded sizes be too small with a larger-than-default yet supported font size
Product: [Frameworks and Libraries] frameworks-kirigami Reporter: popov895 <popov895>
Component: generalAssignee: kdelibs bugs <kdelibs-bugs>
Status: CONFIRMED ---    
Severity: normal CC: 4wy78uwh, alexvkaam, nate, noahadvs, notmart, popov895
Priority: NOR Keywords: regression
Version: 6.6.0   
Target Milestone: Not decided   
Platform: Other   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=490402
https://bugs.kde.org/show_bug.cgi?id=494700
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Visual artifacts

Description popov895 2024-09-26 12:19:55 UTC
Created attachment 174100 [details]
Visual artifacts

SUMMARY

Since the GridUnit has been decoupled from the font size, using a large enough font (Noto Sans 13 in my case) leads to some visual artifacts:
- the content of the color scheme preview tile extends beyond its boundaries
- popup dialogs are not adjusted to the content and have scroll bars, even if they are not needed

SOFTWARE/OS VERSIONS

Operating System: openSUSE Tumbleweed 20240924
KDE Plasma Version: 6.1.5
KDE Frameworks Version: 6.6.0
Qt Version: 6.7.2
Graphics Platform: Wayland
Comment 1 Nate Graham 2024-09-26 17:10:00 UTC
Definitely fallout from the GridUnit change. 13px font is within the supported range, so we should fix this.

Possible fixes include:

1. For each affected layout, base sizes on layouts' implicit widths and heights instead of using hardcoded GridUnit values.
2. Introduce a new global value like "Kirigami.Units.fontSizeMultiplier" that's a multiple of the default font size (which in your case would work out to be 1.3) and then multiply all hardcoded widths and lengths by that.
3. Revert the GridUnit change.

---

#1 is the best approach, but the most work, and also wouldn't fully solve the problem because in some places, we do actually just want a hardcoded size.
#2 is less work but still a lot, and would get us back to basically what we had before, just with a more intuitive API.
#3 Is the easiest.

To be honest, I'm leaning towards #3.
Comment 2 Nate Graham 2024-12-11 22:29:28 UTC
*** Bug 496857 has been marked as a duplicate of this bug. ***