Bug 493687 - 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
Summary: No longer adjusting GridUnit by the font size makes many layouts using it for...
Status: CONFIRMED
Alias: None
Product: frameworks-kirigami
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 6.6.0
Platform: Other Linux
: NOR normal
Target Milestone: Not decided
Assignee: kdelibs bugs
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2024-09-26 12:19 UTC by popov895
Modified: 2024-12-11 22:29 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Visual artifacts (532.20 KB, image/jpeg)
2024-09-26 12:19 UTC, popov895
Details

Note You need to log in before you can comment on or make changes to this bug.
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. ***