https://bugs.kde.org/show_bug.cgi?id=525445
Krzysztof Łastowski <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|kcm_fontinst |Fonts KCM preview images |unconditionally replaces |rewrite the user's |symlinked fontconfig files |fontconfig file on open, |with plain-file copies on |replacing a symlink and |every start |persisting system defaults | |as user settings Component|kcm_fontinst |kcm_fonts --- Comment #2 from Krzysztof Łastowski <[email protected]> --- Correction: I traced this properly, and my description blamed the wrong component and overstated the scope. Retested on Plasma 6.8.1 (Frameworks 6.31.0, Qt 6.12.0, NixOS 26.11), with the source read at tag v6.8.1. What actually happens 1. Opening the Fonts KCM is enough. I clicked nothing and did not expand any combo box, then closed it. Tested both via System Settings and via `kcmshell6 kcm_fonts`. 2. Only one file is rewritten: the first fontconfig file under $HOME that FcConfigGetConfigFiles reports, or fonts.conf / .fonts.conf if one exists (KXftConfig::getConfigFile). Here that is ~/.config/fontconfig/conf.d/10-hm-fonts.conf. The other symlink in the same directory, 52-hm-default-fonts.conf, stayed a symlink. So not "every file under conf.d/". 3. The writer is the KCM's preview image provider, not org.kde.fontinst. Under gdb with a breakpoint on FcAtomicCreate, opening the KCM produced 14 hits, all on a QQuickPixmapReader thread, all with the same stack: #0 FcAtomicCreate () from libfontconfig.so.1 #1 KXftConfig::apply() () from kcm_fonts.so #2 PreviewImageProvider::requestImage(QString const&, QSize*, QSize const&) () from kcm_fonts.so #3 QQuickPixmapReader::processJob(...) from libQt6Quick.so.6 #4 QQuickPixmapReader::processJobs() from libQt6Quick.so.6 #5 QQuickPixmapReader::run() from libQt6Quick.so.6 strace showed the same 14 write cycles (.TMP -> .LCK -> .NEW -> rename onto the target). The rename replaces the symlink with a plain file. A `busctl --user monitor org.kde.fontinst` running during the test saw no traffic to org.kde.fontinst. 4. The file keeps settings the user never chose. Afterwards it contains four extra <match> blocks: rgba=none, hinting=true, hintstyle=hintslight, antialias=true. The cause is in the source. requestImage() reads the "old" values through KXftConfig's getters, writes the preview's values, renders, then writes the "old" values back. But KXftConfig::reset() fills any value missing from the local file with the value parsed from the global files (m_globalFiles, i.e. /etc/fonts). The "restore" therefore writes the system defaults into the user file as explicit local settings. My /etc/fonts/conf.d has 10-sub-pixel-none.conf, 10-hinting-slight.conf and 10-yes-antialias.conf, which match the four values exactly. From then on these local entries override any later change to the system-wide defaults. So two issues, both in kcms/fonts: - Viewing the page writes the user's fontconfig file at all (2 writes per preview image), which also replaces a symlink with a plain file. - The restore turns inherited system defaults into explicit user settings. The fontinst path I originally described does exist: kcms/kfontinst/dbus/Folder.cpp calls FcConfig::addDir(~/.local/share/fonts/) when the service starts. That rewrites the same single file, only while it lacks that <dir> entry. But in these tests fontinst was not started, so it is not what destroyed the symlink here. previewimageprovider.cpp is identical on the Plasma/6.6 branch, where I first reported this. I've retitled the bug to match and moved it to kcm_fonts. -- You are receiving this mail because: You are watching all bug changes.
