| ngraham | |
| davidedmundson |
| Plasma |
Currently the user needs to have a fonts replacment file in /.config/fontconfig/conf.d/ if they want to sync their Plasma font with SDDM.
That's not a good solution because users simply don't have this file or wouldn't know how to create it themselves.
In conjuction with https://github.com/sddm/sddm/pull/1191 this patch removes the need for additional user effort and allows for easy font syncing by writing the Plasma font value to the SDDM config file.
Dependency: https://github.com/sddm/sddm/pull/1191
| No Linters Available |
| No Unit Test Coverage |
| Buildable 15285 | |
| Build 15303: arc lint + arc unit |
We have a mixture of two things.
Here we have a serialised QFont
stored as
font=Lato,11,-1,5,50,0,0,0,0,0,Regular
using these magic methods:
QDataStream &QFont::operator<<(QDataStream &s, const QFont &font)
That tell other code how to turn a QFont object into a string and back. Including family, italics, size, etc.
In the SDDM PR we load that big text as a string, which won't go via that.
We're then using this constructor
QFont(const QString &family, int pointSize = -1, int weight = -1, bool italic = false)
Either SDDM code should deserialize the font (so that the italics and sizes and such work)
Or this code should only write the family name.
This is much better than just setting the font family, I pushed a change in the SDDM pull request to support this now.
Does anything bad happen if the users uses this with a version of SDDM that doesn't support it yet, or does the new item in the config file just get ignored?
Still runs for me and I'm not getting any errors when running the greeter in test mode, but I can't be 100% sure it's not causing any issues.
So the SDDM patch has been merged, but I don't know when the next SDDM release will be. I would keep this on hold until this happens, just to be safe... does that make sense?
I think it should work same as when I submitted the patch. It would be good to add a comment though that this feature is only supported for for SDDM 0.19 and above.
And per this comment nothing bad will happen for versions before 0.19, in case there is some conservative distro out there.
///
@davidre, seeing as this was one of the goals, could you also help me finish T12710? D27461 should likewise just work as is, I just didn't get any +1 on it back then.
Task no.2 was something I couldn't accomplish though. If you have the time and some insight on how to do it, let me know in the task.
I rebased it because of the rewrite that happened, can you check if everything is still ok @filipf
LGTM. Instead of copying the user's entire kdeglobals file (which could also be security risk), the sync function now only reads the font value from kdeglobals and writes it to the kde_settings.conf file. Thanks!
EDIT: Actually the kdeglobals file is still copied because that's where the color scheme is heh.
| src/sddmkcm.cpp | ||
|---|---|---|
| 243 ↗ | (On Diff #83430) | Should I remove this then? |
| src/sddmkcm.cpp | ||
|---|---|---|
| 243 ↗ | (On Diff #83430) | Unfortunately not yet because we still need the kdeglobals file for color schemes. From my previous testing it's not enough to just copy some line colorScheme=Adwaita, we actually need to copy all of the color scheme values written in kdeglobals. IIRC that was also a bit tricky just like recreating the fonts.conf XML file, but it may be possible to reuse existing KDE color scheme functions instead of copy-pasting from config files. |
| src/sddmkcm.cpp | ||
|---|---|---|
| 243 ↗ | (On Diff #83430) | Alright |