[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdelibs-bugs
Subject:    [frameworks-kwidgetsaddons] [Bug 378523] KFontRequester: Fonts are saved with face name preventing b
From:       Fabian Vogt <bugzilla_noreply () kde ! org>
Date:       2018-06-12 16:45:24
Message-ID: bug-378523-90985-JdhJasaTOj () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=378523

--- Comment #65 from Fabian Vogt <fabian@ritter-vogt.de> ---
Git commit 2e971be576d24a82974eaf2397d4703fca0188d8 by Fabian Vogt, on behalf
of R.J.V. Bertin.
Committed on 12/06/2018 at 16:45.
Pushed by fvogt into branch 'master'.

KDE platform plugin: don't force default stylename on user-specified fonts

Summary:

Applying the default, hardwired QFont::styleName to one of the standard fonts
which then gets changed to a user-selected font can break expectations because
of the way Qt handles such canonical stylenames, letting them override the
effects of other QFont methods invoked subsequently. It can for instance become
impossible to make the font bold afterwards: see
https://bugs.kde.org/show_bug.cgi?id=378523,
https://bugreports.qt.io/browse/QTBUG-63792 or
https://bugs.kde.org/show_bug.cgi?id=387467 .

This may be a Qt "feature" that's here to stay, sadly.

The change proposed here makes it possible (again) for users to prevent font
weight rendering regressions by removing the stylename extension from
configuration files manually as documented in several locations. This approach
is useless when the KDE platform theme plugin then applies the default
stylename, an issue that can be avoided by calling QFont::setStyleName() only
when no user-specified font is available.

Evidently the manual intervention could be replaced with a change in the way
font settings are stored; this would also require the current change.

Test Plan:
Works as intended on Linux. An equivalent modification in my osx-integration
fork of the platform theme plugin for Mac has the same effect (without it
"Segoe UI Semi-bold" is no longer made bold where it should in dialogs).

I don't think there are possible side-effects:
- a stylename still gets set either if there is no user-selected font or if
that selection includes a stylename extension
- font specifications should still contain all the required information they
always had; not applying a guessed stylename only means that no conflict can
arise with the combined set of numeric style and weight attributes.

Reviewers: #frameworks, davidedmundson, graesslin, cfeck, dfaure

Reviewed By: dfaure

Subscribers: bkchr, ahmadsamir, rdieter, abetts, anthonyfieroni, ngraham,
cfeck, fvogt, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D9070

M  +4    -1    src/platformtheme/kfontsettingsdata.cpp

https://commits.kde.org/plasma-integration/2e971be576d24a82974eaf2397d4703fca0188d8

-- 
You are receiving this mail because:
You are on the CC list for the bug.=
[prev in list] [next in list] [prev in thread] [next in thread]