Is gtk-fontconfig-timestamp broken?

gnome-font-viewer has an open bug that, when it’s used to install a new font, the installation process never visibly completes — the “Install” button turns to “Installing…” and stays there forever. The new font is also never added to the application’s font list. Only when the program is quit and restarted, will the new font appear.

The reason for this is that g-f-v listens for notify::gtk-fontconfig-timestamp signals on Gtk.Settings, to trigger refreshes of its data model. And those signals never fire, because gtk-fontconfig-timestamp never changes from 0.

I actually wrote a small program to verify this (which both listens for the same signal, and directly probes the value every 10 seconds… getting 0 every time). But I realized after I needn’t have bothered — the gtk4-query-settings tool can be used to verify that the value of gtk-fontconfig-timestamp is always 0.

If I poll the FontconfigTimestamp property of org.gtk.Settings via D-Bus, there I can see the timestamp changing whenever changes are made to the font directories:

$ dbus-send --print-reply --session --type=method_call --dest=org.gtk.Settings \
  /org/gtk/Settings org.freedesktop.DBus.Properties.Get \
  string:org.gtk.Settings string:FontconfigTimestamp
method return time=1736919921.992726 sender=:1.92 -> destination=:1.2199
 serial=337 reply_serial=2
   variant       int64 1736919921252895

$ cp ~/Metropolis_backup/Metropolis-Bold.otf ~/.local/share/fonts/

$ dbus-send --print-reply --session --type=method_call --dest=org.gtk.Settings \
  /org/gtk/Settings org.freedesktop.DBus.Properties.Get \
  string:org.gtk.Settings string:FontconfigTimestamp
method return time=1736920028.880026 sender=:1.92 -> destination=:1.2200
 serial=339 reply_serial=2
   variant       int64 1736920027917491

But instead of returning that same value, this code in an application will always, always set timestamp to 0:

GtkSettings* settings;
guint timestamp;

settings = gtk_settings_get_default ();
if (settings)
  g_object_get (settings,
                "gtk-fontconfig-timestamp",
                &timestamp, NULL);

…And the notify:: signal for the property will never fire, because it never changes.

This completely breaks all of gnome-font-viewer’s update functionality, which is built on the expectation that it will get a notify::gtk-fontconfig-timestamp signal whenever it needs to refresh.

I found this issue that explains the problem: Problems with gtk-fontconfig-timestamp. (#7039) · Issues · GNOME / gtk · GitLab

gtk-fontconfig-timestamp is unimplemented on Wayland, except via the settings portal, and GTK historically hasn’t used the portal for unsandboxed applications. Starting with 4.18, it will always use the portal when available.

1 Like