The failure of the idea of X resources

April 5, 2022

Since the beginning (or very close to it), X has had a resource system (also) to allow central specification of various parameters for programs (at multiple levels). X resources can be used to set options and to customize programs, and one of the things they usually allow you to control is the program's choice of fonts to use. In theory you would think that a central place like your X resources would be a great answer to needing to change all sorts of fonts for programs when you move to HiDPI displays. In practice it's never really worked out this way, and I have some thoughts on that.

One of the problems with X resources is that they're arcane and hard to manage. Even for experienced X people, putting many program options into scripts and window manager configurations has often been the easier way. X resources don't have good answers if you want the same program set up in a few different ways (several setups of xterm, for example), it's generally a complex dance to actually update them in your running session, and it's up to you to keep them organized, among other things. I probably use X resources more than most people who still use them at all, and my usage has steadily been cut back over the years because they're just not very nice.

(X resources can sort of be used to provide different options for different invocations of the same program, but how to do it isn't necessarily obvious, it requires additional command line options to the program, and even programs that use X resources don't always support it.)

A bigger issue with X resources is that by themselves they only solve one level of the issue. They may give me a central place to put configuration information, but (in practice) they require me to configure each program separately. There is no indirection in X resources, not natively, where I could set a 'default monospace font' and a 'default non-monospace font' and have this propagate through to everything. In the Unix way this was "solved" with an extra layer of indirection; the usual process of loading X resources into your session can run the source files through the C preprocessor, so you can use #define to create global settings. But you still have to specify that each program you want to control should use whatever global setting for, say, its font. If you miss a program (or a setting), things fall through to defaults.

(X resources also got badly affected by the migration from XLFD to XFT fonts. In the XLFD era, everything specified fonts in the same way, and often using the same resource name. With XFT fonts, things got much more varied. Some programs specify the XFT font name and size together in one resource, eg 'Monospace-12', while others split it into two resources, font name and font size, and some require you to tell them you want an XFT font, eg 'xft:Monospace-12'. The resource names aren't necessarily consistent either. This makes any sort of global setting through #defines rather more annoying.)

Modern Unix settings systems do tend to have such global defaults, although part of that is that they often see themselves as part of a coherent system of programs (Gnome programs, KDE programs, etc), and a coherent system naturally has a system-wide default.

Another issue is that X resources are a product of their time (to be charitable), and that time is long passed. Modern systems tend to integrate some degree of documentation for the settings, more or less live changes, some degree of discoverability and hierarchy, and exposes a GUI for changing things, for good reasons. X resources assume that the manual pages and a text editor are good enough (I know, real mavens read through /usr/share/X11/app-defaults too, never mind that many of those files have settings that aren't intended to be user serviceable).

In some ways I do like my X resources; at least they're in some text files that I can look at, they let me set xterm's behavior across all of the machines I use it on, and I can pull out the live settings from the X server if I want to. But in other ways I think I would be better off if everything used gsettings or gconf or something, with defaults and the ability to navigate through the keys and interact with values.

Written on 05 April 2022.
« Things I needed to change for HiDPI on Linux that weren't in my X settings
Fedora now has a sensible UEFI boot setup (and has for some time) »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Apr 5 23:38:18 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.