There has been a lot of commentary recently about Gnome, and a common source of confusion seems to be Gconf – what is it, how does it work, and so on. Some people even seem to confuse Gconf with the registry database in Windows. I will attempt to clear some of this confusion and give an overview of Gconf, and why it looks the way it does.Dot files
Most applications in Unix or Unix-like systems use “dot files” as the way to set and save configuration information. These files are saved in the user’s home directory (and can be a whole subdirectory of files if the app is complex). In addition, many apps support the idea of system-wide defaults, with a separate configuration file that sets defaults when the user has not set any preferences themselves.
This system would be simple and straightforward, but it has some limitations.
First, every app has its own file format. Many apps have a variant of “keyword = value”; others use tab-separated (or comma separated, or colon-separated…) values. Applications that are programmable (including bash, Emacs and Vim) favor having config-files that are scripts, executable by the application. As a user, I need to keep track of dozens of different formats (and a few small programming languages) if I want to do any serious reconfiguration. And creating a front end to all of this would be very, very difficult.
Second, these files are all in my home directory, intermingled with my other stuff. Individual apps are becoming pretty good at organizing themselves (more than half of my one-hundred or so dot files are actually directories), but it would be nice if the config stuff could all be collected in a subdirectory of its own. If nothing else, you would know that anything there is a configuration file, not image caches, logs or whatever.
Third, system-wide defaults are spread out all over. Some apps put them in /etc, some in /usr/X11R6/lib/X11 somewhere, others are in their /usr/share directories. Some do not even support the idea of system defaults. Again, it would be preferable to have them collected under one directory somewhere.
So, what we would like, really, is to have text-based config-files, in a common format, and organized in a directory hierarchy. Also, the system-wide defaults would have the same structure, and reside in one place. Add an API for easy application development, and user tools to handle these without having to edit stuff by hand.
Gconf really is three things: structured storage of settings; an application API for changing settings and getting notified about changes; and user tools to edit their settings in a more convenient manner than editing dot files by hand. These three components are largely independent of one another. One could have a different storage mechanism (as tables in a company-wide database server for distributed access, for example); different API:s for other desktops; and different or complementary user tools (see Gnome-Extra-Setup for one example).
Current Gconf storage is exactly as described in the previous section: dot files in a common text format (XML), in a structured hierarchy of subdirectories (under ~/.gconf for each users settings, and /etc/gconf for system-wide defaults). An application using Gconf will use the system default unless the user has set it differently locally, just as for most dot files. The user’s Gconf directory will in fact only have those keys that have been changed from the system defaults.
In addition, there are “schema files”, which is just installation defaults for all the settings, and are copied over to be the initial setting when the application is installed.
Again, all of Gconf is editable by hand. If you want to, you can treat it as just another variant of a dot file, with the benefit that a lot of apps share the same file format and organization.
Of course, with a reliable organization and a rich back end format, we can do more than just treat them as uncorrelated dot-files. We can have settings that apply for more than one application – or for the whole desktop – and be confident all affected applications can read them.
We can have an easy API for applications to set and read settings – no need for every app to use an XML parser (or any dot file parser for that matter). We can also let applications tell what settings they are interested in, whether their own or system-level settings that may affect them. That way the app can find out directly when a setting changes and act accordingly.
To do so, we have a daemon (gconfd) waiting for changes to settings. When it occurs, this daemon checks what apps (if any) wants to know about this, and tells them about it.
We also have some user and administration tools. gconftool is a command-line tool, mainly meant for use by installation scripts and other automated tasks. For interactive use, we have gconf-editor (usually called “configuration editor” or something similar in the menu) as a clean way to present all available settings for the user to edit, and not jsut those chosen to be exposed by the author.
Since the storage format is rich, gconf-editor can present the options in a manner very much like a dedicated settings window; it knows what data type an option wants, and it can show help texts for the individual options. And since we use Unicode, we can have these texts translated as well. Since Gconf is the way for apps to store all their configuration data, it means we get a nice, organized way to edit even the most obtuse options.
A separate question is of course what options should be available directly in the application’s own config dialog, and which should be accessible only through the configuration editor. Some options are obviously needed in the main config dialog; others are just as clearly not. For the remaining, ambiguous ones, the decision of course ultimately comes down to the maintainer of the individual application. No matter what his or her decision may be, though, the configuration editor allows anyone to edit it in a painless way.
To recap, Gconf really is three different, but related things. It is an organized way to store configuration files; it is an application API to handle settings in a transparent manner; and it is user tools to examine and change any setting an application may have, with instant feedback and help.
About the Author:
Jan Morén is a translator for the Swedish Gnome translation project, and currently resides in Japan.