Yesterday I mentioned the XSettings standard for exposing (some) toolkit related configuration options to theoretically interested parties in a theoretically toolkit-independent way. There are some slightly non-obvious or not entirely documented things about this and daemon support for it.

First, as hinted by the 'X' in the name, this is is not a DBus-based system. Instead it uses the old-fashioned approach of setting an X property on the root window and having programs read this property. Because this is an X property, all clients can see it, whether they are on the local machine or on a remote machine. In turn this means that remote clients may change their behavior if you start running xsettingsd or the like, because now they can see your (local) configuration settings. How your local configuration settings interact with what's available on a remote machine can be potentially chancy; for example, it's perfectly possible to specify a Gtk/FontName that doesn't exist on other machines.

Some but not all settings daemons have side effects when run. For example gnome-settings-daemon appears to also add some X resources for things like Xft settings. This itself can cause (some) programs to change their behavior, even if they don't use a toolkit with support for XSettings. As far as I can tell, xsettingsd does not do this.

At least xsettingsd allows you to set essentially arbitrary settings properties, including in existing namespaces; for instance, it sure looks like you can set all sorts of XFT properties in XSettings. However, this is an illusion. In practice, there is a small set of known shared settings for general cross-toolkit things and if something's not in there, you setting it will do nothing. Where this really starts to matter (at least to me) is that the available XFT settings are pretty minimal. In particular, they don't include the fontconfig lcdfilter setting, which turns out to be one of the settings necessary to get fonts to look how I want them to.

(It's not clear to me if lcdfilter can be set in the Xft.* X resources either. I suspect not, but it probably can't hurt to try.)

At the same time, modern GTK has way more settings exposed through XSettings than are documented in the registry. To find out what all of them are, you basically need to fire up gnome-settings-daemon temporarily and run dump_xsettings to extract them all. I don't know what settings KDE exposes (if any); I haven't tried to find and run the KDE equivalent of gnome-settings-daemon.

For XFT settings specifically, I'm not sure what reads XSettings, what reads the X resource database, and what ignores all of this. I expect that GTK applications read XSettings, but I've seen some basic X programs like xterm appear to read either XSettings or X resources or perhaps both.

(And gnome-settings-daemon itself seems to do at least some DBus stuff, although I don't know if that's used for querying settings. All of this is annoyingly complicated. See this blog entry from 2010 for a picture of how complicated it was back then, and it's probably worse now.)

On the whole, if you have a mostly or entirely working environment now without a settings daemon involved, it seems safest to have the daemon publish only an extremely minimal set of XSettings settings. I started out feeling quite enthused about setting all of the XFT options but I'm now shifting more and more towards publishing only Gtk/FontName as the minimal fix for my issues. Of course, the mere existence of an active XSettings daemon may change program behavior (most especially including on remote machines), but you take what you can get in the world of modern X.