GConf: Manageable User Preferences Havoc Pennington Red Hat, Inc.
[email protected], http://pobox.com/˜hp Abstract liMirror and ACAP. Finally, it presents some initial ideas for a Phase Two version of GConf. GConf is a system for storing user prefer- Phase Two is very much a work-in-progress. ences, being deployed as part of the GNOME 2.0 desktop. This paper discusses the ben- 2 Motivation efits of the GConf system, the strengths and weaknesses of the current implementation, and plans for future enhancements. Several years ago it was becoming obvious that GNOME’s initial approach to storing prefer- ences (a simple API for writing key-value pairs 1 Introduction to files) had a lot of limitations: GConf started out very simply in late 1999, as • It did not work for preferences that af- my first project at Red Hat. It was a straightfor- fected or were manipulated by multiple ward response to concrete problems encoun- applications, because there was no way tered while creating the GNOME desktop, and for applications to know a setting had designed to be implementable in a few months changed. GNOME 1.x contains numerous by a programmer with limited experience (i.e., hacks to work around this, and apps have by me). Much of the current implementation to be restarted before certain preferences (let’s call it Phase One) was created at that take effect. time. • Administration features were missing, GConf saw some limited use as part of the such as applying different defaults to dif- GNOME 1.4 platform—specifically in Nau- ferent groups of users, or storing defaults tilus and Galeon—but it wasn’t widely adopted for many machines on one network server.