1162369 - handle fontconfig updates using gtk signals

Status: NEW

(Core :: Graphics: Text, defect, P3)

Description

[John Daggett (:jtd)]

In a comment on bug 1056479, Behdad mentioned that the current preferred way of handling font additions/removals is to use the gtk signals API:

https://bugzilla.mozilla.org/show_bug.cgi?id=1056479#c63

This makes a lot of sense I think, for both the existing Pango font group code and the new fontconfig platform fontlist.

GTK provides a way for apps to register to receive notifications of when the fontconfig timestamp changes. This is a better way to respond to font additions and removals than manually using the fontconfig rescan interval.

I'm not sure where exactly this should be handled but one place might be within the UNIX app startup code here:

http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsNativeAppSupportUnix.cpp#138

The code here would register a callback to call through to gfx to update the system fontlist (gfxPlatform::UpdateFontList). Another place might be within gfxPlatformGtk startup code (e.g. gfxPlatformGtk::CreatePlatformFontList).

Comment 1

[Karl Tomlinson (:karlt back Feb 10)]

(In reply to Behdad Esfahbod from bug #1056479 comment #63)
> Note that on the Linux desktop we ignore the fontconfig rescan interval and
> use file monitoring and xsettings to propagate a change notification. 
> Applications using Gtk+ can subscribe to be notified on the
> notify::gtk-fontconfig-timestamp signal of GtkSettings object.  At this
> point, I don't know any system that actually uses the fontconfig rescan
> interval.

Thanks for your comments, Behdad, but it's better if non-GNOME-specific apps don't depend on gnome-settings-daemon, as it is not necessarily running.

All apps that use FcFontSetList of FcFontList are using rescan interval, whether they know it or not.

I guess we could listen to the signal if we know that an XSETTINGS daemon is scanning for us, but then we'd need to also have code to support systems where that is not happening.

Comment 2

[Behdad Esfahbod]

(In reply to Karl Tomlinson (ni?:karlt) from comment #1)
> (In reply to Behdad Esfahbod from bug #1056479 comment #63)
> > Note that on the Linux desktop we ignore the fontconfig rescan interval and
> > use file monitoring and xsettings to propagate a change notification. 
> > Applications using Gtk+ can subscribe to be notified on the
> > notify::gtk-fontconfig-timestamp signal of GtkSettings object.  At this
> > point, I don't know any system that actually uses the fontconfig rescan
> > interval.
> 
> Thanks for your comments, Behdad, but it's better if non-GNOME-specific apps
> don't depend on gnome-settings-daemon, as it is not necessarily running.

That's a fair point.  The XSETTINGS machinery is not GNOME-specific, but I don't know if other desktops have embraced it.  I can test Unity and KDE tomorrow.


> All apps that use FcFontSetList of FcFontList are using rescan interval,
> whether they know it or not.

Looks like it.  Thanks.  I had a vague memory that it doesn't do that automatically but apparently I was wrong.


> I guess we could listen to the signal if we know that an XSETTINGS daemon is
> scanning for us, but then we'd need to also have code to support systems
> where that is not happening.

Really depends on whether Unity and KDE need that.  I like the fact that with the XSETTINGS/GTK+ wiring, changes appear live.  In existing systems, it takes about 4 5 seconds.  We reduced that to 1 2 seconds.  Without monitoring, you are back to the 30 seconds.  It's a different experience that may or may not be ok.

Anyway, here's the monitoring code from gnome-settings-daemon.  Normally, you don't want every app to install file / directory monitors on a 100 locations.  But for a browser, that's not totally unreasonable.

  https://github.com/behdad/fontconfig-monitor

Thanks.