| Summary: | Plasma always forces its own font configuration breaking system one | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | Giusy Digital <kurmikon> |
| Component: | kcm_fonts | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | agurenko, bhush94, ceggy, katyaberezyaka, kde, nate, unassigned-bugs |
| Priority: | NOR | ||
| Version: | 5.17.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Giusy Digital
2019-10-18 09:34:18 UTC
>The only way I can avoid this behavior is to symlink ~/config/fontconfig to /dev/null, which is unacceptable on a desktop environment like Plasma that claims to be highly customizable.
Your other option is to copy those defaults into /etc/xdg/kdeglobals
Adding support for this is most of the rationale for removing vendor default. kdeglobals still supports setting the hintsettings to "notset" which will then not affect fontconfig.
IMHO, not a bug, other than maybe some documentation work.
Not a bug? It broke my config and this should not be considered a bug? When you broke something as a developer, do not expect the user to fix it in a configuration file. Please, fix it in the graphic interface. I think people uses Plasma Desktop to configure things by the graphic interface, not for writing in a text file because you chose a bad configuration as the default. There's also the issue that disabling the antialiasing in the kcm will gray out the other options, which is completely meaningless. >I think people uses Plasma Desktop to configure things by the graphic interface, Those people are not remotely affected. Only people who have modified configs manually at some point anyway. The issues comes from KDE having a simplified version of the settings and fontconfig having a super-duper blown mega complex config, which we couldn't possibly summarise in a UI. Then we're in a classic problem of having two sources of truth. one solution we could do is make use of fontconfig cascading and put things in: $XDG_CONFIG_HOME/fontconfig/conf.d/00-kde.conf then we wouldn't risk overriding other files. It means the KCM could occasionally lie, but only if a user has gone out of their way to do their own fonts meddling - at which point it's on them. >There's also the issue that disabling the antialiasing in the kcm will gray out the other options, which is completely meaningless. Yes. Though it's best if we don't mix up bug reports with multiple topics. First thing to do is to readd "leave system congif" which was previously present and don't know for what reason it was removed. That could just resolve the issue leaving the local config file empty. Then writing kcm config in a separate config is a good idea also. One thing that I can't follow is you say your fontconfig were changed just on it's own? I can see how they're overwritten if you open and close the font KCM, but I can't see a path that syncs on startup. (In reply to David Edmundson from comment #5) > One thing that I can't follow is you say your fontconfig were changed just > on it's own? > > I can see how they're overwritten if you open and close the font KCM, but I > can't see a path that syncs on startup. My system-wide fontconfig was not changed. Kcm keeps rewriting its own fontconfig and there's no way to keep it empty avoiding to override the system options. I noticed this behavior at the opening of the kcm and at the start of the session. In every case, the file emptied before was rewritten after. Maybe this is not a big issue for the majority of users, but it's not a good behavior. Just write what the user choose in the kcm and give him/her the chance to keep it empty leaving the option to rely on system ones. I believe this happens also on KDE Plasma 5.26.5, as when I set the rgb sub-pixel rendering setting to None, some text have grayscale rendering while others have rgb rendering. I expect the all text to honor my fontconfig settings The issue described in this bug was fixed a few years ago. The issue of not respecting the "no rgb anti-aliasing" is something else: bug 463024. (In reply to Nate Graham from comment #8) > The issue described in this bug was fixed a few years ago. The issue of not > respecting the "no rgb anti-aliasing" is something else: bug 463024. Oh okay, thank you |