This patch explicitly sets the QML text rendering variable for Kickoff
tab labels as QtRendering. The effect is that the tab labels are now
properly kerned.
Details
Details
Before:
After:
Explanation:
Kerning refers to the spacing between letters in text. It's important to get it right because otherwise the UI can look unprofessional (and ugly). Currently there is a QML bug that renders all NativeRendering elements with bad kerning. The tab labels in Kickoff are highly affected and you often get "His tory" "L ea ve" and other combination of bad spacing.
Since: (1) we are polishing the presentation of Kickoff in other diffs, (2) the kerning bug appears almost always in the tab section, (3) it looks like there isn't much progress in the upstream bug report; it would be beneficial to address this visual issue with a small workaround that entails setting rendering to QtRendering, which doesn't suffer from kerning issues.
Disclaimer:
I am the biggest opponent of working around upstream bugs, but this wouldn't be a precedent because we already do the same with the clock in the SDDM theme, and it's a minor change applied to the place where the bug most critically manifests itself. I'd promise to remove this from future versions as soon as QT provides a fix.
Diff Detail
Diff Detail
- Repository
- R119 Plasma Desktop
- Branch
- kickoff-kerning-workaround (branched from master)
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 5161 Build 5179: arc lint + arc unit
This comment was removed by filipf.
Comment Actions
this has been bugging me/us for years, glad you finally decided to patch it :D
(no pun intended)
This comment was removed by rooty.
Comment Actions
QtRendering renders a lot better.
(LOL I accidentally removed the comment)
NativeRendering really is the gift that keeps on giving.
QtRendering renders a lot better.
This is actually pretty neat considering Kickoff and Notifications are the only two widgets where this is a noticeable problem.
P.S. It got taken off Netflix. Don't judge me 🤣
Comment Actions
This is actually pretty neat considering Kickoff and Notifications are the only two widgets where this is a noticeable problem.
And the icons on the desktop (not a widget though, yeah).
Comment Actions
Widget explorer also shows this behavior, however this is more a problem of the labels being not aligned to a pixel grid rather than NativeRendering
Comment Actions
This isn't an acceptable patch, sorry - we can't just randomly sprinkle a different font rasterizer into the UI. The rasterization should be consistent throughout the system and consistent with applications, where FreeType (i.e. NativeRendering) is the default. Qt's SDF rasterizer (QtRendering) is also low-quality and unsuitable for many type faces.
Comment Actions
Someone's already done this though. Check line 32 on the left here: https://phabricator.kde.org/differential/changeset/?ref=300659&whitespace=ignore-most (can't find the repo version)
Comment Actions
Thanks, that should probably be reverted, although there might have been some reason I'm unaware of in that case since it also sets the font style to outline rendering.
Comment Actions
The notifications widget also forces NativeRendering in one of its components rather than leave it open for discussion. Inconsistency regarding font rendering is already a foregone conclusion. Unfortunately, however consistent NativeRendering may be, it just doesn't pass muster. (This contributes to why designers and book publishers prefer mac over windows).
Also it's hardly random, it's specifically targeted at a label or a single portion of the UI that's affected by this gravely and consistently.
Why should it be reverted? If it worked without anyone even noticing it did, how can this be a problem? If it ain't broke...
Comment Actions
The notifications widget also forces NativeRendering in one of its components rather than leave it open for discussion.
It does because it's using a TextEdit directly to make text selectable rather than a full TextArea which would set this automatically internally.
Comment Actions
Yeah but it looks like it needs an attitude adjustment. Wouldn't sacrificing selectability be acceptable in this case?
Comment Actions
Yes, I just logged in and out 10 times and 10 times out of 10 the kerning came out garbled.
Comment Actions
FWIW, we already conditionally switch to using QtRendering when using a fractional scale factor throughout the PlasmaComponents library. So there is already a precedent for sometimes using a different renderer to work around visual bugs, and so far it has been much appreciated by our users. Doing it there rather than in individual UI elements is probably right right place for this change rather than in individual UI elements in widgets, if it's to be done at all.
Of course, the upstream bugs should be fixed, for sure.
Comment Actions
That's a much more elegant solution. I assume the problems were bigger there, thus warranting such an intervention.