If your program detects duplicates updates the mtime of the directories, that triggers to rebuild caches as I said earlier. that isn't "nothing changed".
Anyway, we may need to think about this again. for instance, adding an API to enable/disable the cache updates automatically in fontconfig or get rid of it completely and giving a responsibility to the applications to do it may be good perhaps.
On Tue, Nov 29, 2016 at 2:22 PM, L. A. Walsh <fonts@xxxxxxxxx> wrote:
Akira TAGOH wrote:
On Tue, Nov 29, 2016 at 8:40 AM, L. A. Walsh <fonts@xxxxxxxxx <mailto:fonts@xxxxxxxxx>> wrote:---
Keith Packard wrote:
We might as well just stop attempting to automatically manage
the caches
and require that users run fc-cache manually whenever they
change the
set of installed fonts. That would push the whole problem out of
fontconfig and onto the user or distribution...
---
That would be preferable, since the user might want to install
100 fonts and then build a cache rather than have it rebuilt with
each font installed.
That said you are facing this issue because you didn't do that.
I didn't install any fonts.
I ran a prog to look for duplicates and link them if
it found any.
So reality is "nothing changed", but it regenerated the
cache anyway.
once we stop attempting to automatically creating/updating/removing caches, you'll see another problem, "hey, no fonts is available" ;)----
Why doesn't windows have this problem? At worse, they have to
reboot, but usually, added fonts are available immediately.
Thinking of seeing such issues many times, I'm wondering if leaving the cache creation to the users would be really a good idea.==== Great -- yeah, never give users control of their computers -- treat
them all like children. If your prog didn't take so long to process 1
new font, it wouldn't be an issue.
Akira TAGOH
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
