Some things about the XSettings system
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.
|
|