Skip to content

Problems with gtk-fontconfig-timestamp.

Steps to reproduce

Run a gtk 4 application under Wayland, outside a flatpak sandbox.

Make a change to the font configuration on the system, adding or removing a font from ~/.fonts/ is sufficient.

Note that the changes are not picked up by the application, if a new font was added, it is not visible to the application.

Use touch to add a dummy file in ~/.fonts/: touch ~/.fonts/dummy_file

Note that the changes are still not picked up by the application, if a new font was added, it is not visible to the application.

Remove the dummy file (rm ~/.fonts/dummy_file), and revert whatever other change was made to the font configuration.

Now, run the same application, but with GDK_DEBUG=portals set in the environment.

Make a change to the font configuration on the system, adding or removing a font from ~/.fonts/ is sufficient.

Note that the changes are not picked up by the application, if a new font was added, it is not visible to the application.

Use touch to add a dummy file in ~/.fonts/: touch ~/.fonts/dummy_file

Note that the changes have been picked up by the application. If a new font was added, it should now be visible to the application.

Current behavior

Font configuration changes are not picked up at all under Wayland unless portals are used for settings.

If portals are used for settings, changes are only picked up after another additional change is made.

Expected outcome

Changes to the local font configuration should be picked up by gtk 4 applications immediately.

Version information

GTK 4.16.1, however the bugs still exist on the current git main HEAD.

Debian sid.

Note that for the portal behavior to show up, either xdg-desktop-portal-gnome or xdg-desktop-portal-gtk must be installed and running.

Additional information

There are really two different (though related) bugs showing up here.

One of them should be a trivial fix, in gtk/gtksettings.c, inside the settings_update_fontconfig function, it currently has the following:

      if (PANGO_IS_FC_FONT_MAP (fontmap) && !FcConfigUptoDate (NULL))
        {
          pango_fc_font_map_config_changed (PANGO_FC_FONT_MAP (fontmap));
          if (FcInitReinitialize ())
            update_needed = TRUE;
        }

The call to pango_fc_font_map_config_changed needs to be moved to after the FcInitReinitialize call, so that pango can pick up the changes introduced by FcInitReinitialize.

That is sadly the easy problem.

The hard problem is that currently gdk has no way to get a value for gtk-fontconfig-timestamp under Wayland except via the portal.

Under X11, it attempts to read Fontconfig/Timestamp via xsettings, and while decidedly imperfect, that works when we are running under a gnome session.

Under Wayland, when we are not running inside a Flatpak sandbox, gdk attempts to get most settings via gsettings directly.

Unfortunately, nothing in gsettings provides a value that can be used for gtk-fontconfig-timestamp, and so gdk/wayland/gdkdisplay-wayland.c simply uses a hard coded value of 0 outside of the sandbox.

That is decidedly suboptimal, especially if the system has xdg-desktop-portal running.

I can see a few different ways forward, and I'm not sure which would be preferred.

  1. Outside of the sandbox, attempt to use xdg-desktop-portal by default, and only fall back to gsettings if for some reason we are unable to get settings from the portal.
  2. Outside of the sandbox, use gsettings for most things, but attempt to use xdg-desktop-portal for any settings that we can not get via gsettings. The main case here being gtk-fontconfig-timestamp.
  3. Attempt to monitor for fontconfig changes ourselves.
  4. Document the problem, and provide an API which can be used to tell gtk to check for fontconfig changes. For the Wayland case, having that API call FcConfigUptoDate(NULL), and then incrementing gtk-fontconfig-timestamp should be sufficient.

Option 1 would be fairly trivial to implement, however I am unsure if there would be other less desirable consequences to this change.

Option 2 would be more painful to implement, but it's definitely possible.

I don't think that option 3 is practical, the consequences of having every single gtk application trying to monitor the fontconfig files in the same way that the desktop portals do seems like a bad call all around.

And I think that option 4 would be a nasty kludge, not a sane option.

Having an internal task that periodically did what is described for option 4 might be an option, but again, the consequences of each application doing that on their own seems a bit suboptimal.

(As an aside, I'm happy enough doing some of the work required for any path forward, however I'll need to jump through some hoops at work to get permission to contribute to the gnome project in my off hours, so I'm holding off on that until I get some feedback.)