On 15 Jan 2016, Keith Packard told this: > It could, in theory, run a separate thread to monitor font directories > for change and automatically rebuild the list on the fly. However, > fontconfig isn't exactly the most thread-friendly library in the world, > having been designed before application-level threading was common... In addition to being excessively complex, you can't rely on such a mechanism working anyway, because many network filesystems have no reliable notification mechanism built in, and inotify/dnotify/etc are local-only. This whole thread, after all, started because of people living in the last century like me who keep either systemwide or $HOME-based fonts, or both, on shared network filesystems -- i.e. the sort of people who used to use the X font server before client-side fonts were a thing. In practice, any application that's going to *use* a bunch of fonts that are likely to be installed in a recently-updated directory probably just installed them itself, and can request a rescan itself. (That's not to say it *does*, and of course there is still the edge case of someone who tries to use some font in a long-running app, finds it's not there, installs it using the distro tools and then gets annoyed because the mapped font cache is out of date and the app almost certainly has no way to explicitly refresh it so they have to restart to pick it up. Nobody's even *tried* to fix that problem, though it seems like a fairly plausible use case to me. Even Emacs, almost the canonical annoying-to- shut-down long-running application that uses lots of fonts, or at least the canonical one that programmers use, has no function exposed to Lisp to rescan the Fontconfig cache.) -- NULL && (void) _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
