Review Request: Do not modify .fonts.conf when loading it. Now nothing is written before the user clicks apply or ok. Fixes Bug 105797.

[Nikolaus Waxweiler]

> On May 26, 2011, 2:03 p.m., Thomas Lübking wrote:
> > > Would there even be any good alternative approaches?
> > Yes, 
> > - properly read the fontconfig (including global settings)
> > - only write settings actually touched by the user
> > - have a checkbox to disable custom font configuration (i.e if not enabled, store the settings in a private config for later use, but wipe the ~/.fonts.conf

I don't know about accurately reading all of fontconfig, my impression is that fontconfig files are write-only (hence the comment about fickleness -- it's like reading in HTML pages and trying to make sense of them programmatically for all possible variations of an HTML page). And even if it was done, what benefit would you get? How often do you change your font rendering? The only thing that would currently make sense to me would be something like Windows ClearType Tuner, where you can select the subpixel order and the "thickness" or "blurriness" of the rasterization by clicking on a rendering that you like best. This could be useful to adapt the rendering to low-quality and/or misadjusted displays that can't be manually adjusted for whatever reason. And, more importantly, it would improve usability tremendously ("Full hinting? What's that?"). Fontconfig needs to be modified to recognize those settings. A patch in that direction is in the works afaik as part of Infinality's FreeType patches (which wonderfully demonstrate how KDE's font dialog bulldozes over carefully crafted font configurations). I was thinking about overhauling the current font dialog (and throw out the many fields, but have since defected to Gnome/Unity...

Anyway, has this patch finally been commited? It should help with your second point. The third point seems good, but a custom config is disabled by default anyway. My patch makes sure that this is actually respected. Before, the dialog would write a custom config even if the setting was do-not-change-the-system-defaults! I'm actually surprised that this bug was there for so many years. Annoyed me first during KDE 3.5.x. Maybe nobody ever cared because nobody ever changed the default font rendering settings and was therefore never hit by the bug, which makes the setting itself questionable ;)


- Nikolaus


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101359/#review3538
-----------------------------------------------------------


On May 25, 2011, 8:11 p.m., Nikolaus Waxweiler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101359/
> -----------------------------------------------------------
> 
> (Updated May 25, 2011, 8:11 p.m.)
> 
> 
> Review request for KDE Base Apps and KDE Runtime.
> 
> 
> Description
> -------
> 
> I simply removed all code in loading routines that wrote something to the config.
> 
> On a side-note, I'd love to rip out the whole fontconfig configuration completely... I think that the whole modifying-.fonts.conf-approach is too fickle because the system/distribution can set up elaborate hinting/antialiasing configurations and the changes made to .fonts.conf just bulldoze over them. Most people will probably never (really want to) touch those settings anyway (Windows and Mac OS X users at least don't seem to, and they don't appear to be unhappy about it)... Would there even be any good alternative approaches?
> 
> 
> This addresses bug 105797.
>     http://bugs.kde.org/show_bug.cgi?id=105797
> 
> 
> Diffs
> -----
> 
>   kcontrol/fonts/fonts.cpp 0cd2666 
>   kcontrol/fonts/kxftconfig.cpp 9cd04de 
> 
> Diff: http://git.reviewboard.kde.org/r/101359/diff/diff
> 
> 
> Testing
> -------
> 
> - Delete .fonts.conf and see if invoking "kcmshell4 fonts" creates it again without user intervention
> - Delete various match-settings set by the kcm (e.g. hintstyle and rgba) and see if it recreates them while leaving match-settings not deleted untouched
> - Switch anti-aliasing settings between system, disbled and enabled and apply each time, change some aa-settings while enabled and check if they stay there after switching
> 
> 
> Thanks,
> 
> Nikolaus Waxweiler
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120116/bf077c08/attachment.htm>