Do we want to add a glib dep to fontconfig?
just wonder if the sort of this feature should goes into the toolkits like GTK+ and Qt or whatever. so it can be integrated to their mainloop easily.

Oh I meant just moving the code into fontconfig tree under its own subdirectory.  Maybe if user has glib, build it as fc-monitor, with a useful output format.  Didn't mean to merge it into the library.

Code updated and improved.  See:
https://github.com/behdad/fc-monitor

I can just put it in fontconfig/fc-monitor, with its separate build Makefile as is.

Sure. though I'm not sure if we should build it because it doesn't do more than checking updates and we don't have a way to stop that in apps so far. so people doesn't have any advantage to run it.

We may merge https://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=disable-auto-update as well?

(In reply to Akira TAGOH from comment #4)
> Sure. though I'm not sure if we should build it because it doesn't do more
> than checking updates and we don't have a way to stop that in apps so far.
> so people doesn't have any advantage to run it.
> 
> We may merge
> https://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=disable-auto-update
> as well?

What problem is that trying to solve?  How do you see it used?  Ie. by Gtk+?

(In reply to Akira TAGOH from comment #4)
> Sure. though I'm not sure if we should build it because it doesn't do more
> than checking updates and we don't have a way to stop that in apps so far.
> so people doesn't have any advantage to run it.
> 
> We may merge
> https://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=disable-auto-update
> as well?

I prefer that we fix scanning speed and remove the blocking lock instead of adding bandaid API.

I don't think we can get rid of the lock. improving the scan speed would just make things hard to see. but can't be zero unless making the update process to be singleton as I suggested before. improving the scan speed itself would be very useful though, it isn't the essential solution to remove the lock. need an extra idea to avoid breaking a cache and detect it before writing otherwise we can't simply do that.

(In reply to Akira TAGOH from comment #7)
> I don't think we can get rid of the lock. improving the scan speed would
> just make things hard to see. but can't be zero unless making the update
> process to be singleton as I suggested before. improving the scan speed
> itself would be very useful though, it isn't the essential solution to
> remove the lock. need an extra idea to avoid breaking a cache and detect it
> before writing otherwise we can't simply do that.

Ok, let's continue on the email thread.  I'll comment there.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/89.