1DCONF(7)                 Conventions and miscellaneous                DCONF(7)
2
3
4

NAME

6       dconf - A configuration system
7

DESCRIPTION

9       dconf is a simple key/value storage system that is heavily optimised
10       for reading. This makes it an ideal system for storing user preferences
11       (which are read 1000s of times for each time the user changes one). It
12       was created with this usecase in mind.
13
14       All preferences are stored in a single large binary file. Layering of
15       preferences is possible using multiple files (ie: for site defaults).
16       Lock-down is also supported. The binary file for the defaults can
17       optionally be compiled from a set of plain text keyfiles.
18
19       dconf has a partial client/server architecture. It uses D-Bus. The
20       server is only involved in writes (and is not activated in the user
21       session until the user modifies a preference). The service is stateless
22       and can exit freely at any time (and is therefore robust against
23       crashes). The list of paths that each process is watching is stored
24       within the D-Bus daemon itself (as D-Bus signal match rules).
25
26       Reads are performed by direct access (via mmap) to the on-disk database
27       which is essentially a hashtable. For this reason, dconf reads
28       typically involve zero system calls and are comparable to a hashtable
29       lookup in terms of speed. Practically speaking, in simple non-layered
30       setups, dconf is less than 10 times slower than GHashTable.
31
32       Writes are assumed only to happen in response to explicit user
33       interaction (like clicking on a checkbox in a preferences dialog) and
34       are therefore not optimised at all. On some file systems, dconf-service
35       will call fsync() for every write, which can introduce a latency of up
36       to 100ms. This latency is hidden by the client libraries through a
37       clever "fast" mechanism that records the outstanding changes locally
38       (so they can be read back immediately) until the service signals that a
39       write has completed.
40
41       The binary database format that dconf uses by default is not suitable
42       for use on NFS, where mmap does not work well. To handle this common
43       use case, dconf can be configured to place its binary database in
44       XDG_RUNTIME_DIR (which is guaranteed to be local, but non-persistent)
45       and synchronize it with a plain text keyfile in the users home
46       directory.
47

PROFILES

49       A profile is a list of configuration databases that dconf consults to
50       find the value for a key. The user's personal database always takes the
51       highest priority, followed by the system databases in the order
52       prescribed by the profile.
53
54       On startup, dconf consults the DCONF_PROFILE environment variable. If
55       set, dconf will attempt to open the named profile, aborting if that
56       fails. If the environment variable is not set, it will attempt to open
57       the profile named "user" and if that fails, it will fall back to an
58       internal hard-wired configuration. dconf stores its profiles in text
59       files.  DCONF_PROFILE can specify a relative path to a file in
60       /etc/dconf/profile/, or an absolute path (such as in a user's home
61       directory). The profile name can only use alphanumeric characters or
62       '_'.
63
64       A profile file might look like the following:
65
66           user-db:user
67           system-db:local
68           system-db:site
69
70
71       Each line in a profile specifies one dconf database. The first line
72       indicates the database used to write changes, and the remaining lines
73       indicate read-only databases. (The first line should specify a user-db
74       or service-db, so that users can actually make configuration changes.)
75
76       A "user-db" line specifies a user database. These databases are found
77       in $XDG_CONFIG_HOME/dconf/. The name of the file to open in that
78       directory is exactly as it is written in the profile. This file is
79       expected to be in the binary dconf database format. Note that
80       XDG_CONFIG_HOME cannot be set/modified per terminal or session, because
81       then the writer and reader would be working on different DBs (the
82       writer is started by DBus and cannot see that variable).
83
84       A "service-db" line instructs dconf to place the binary database file
85       for the user database in XDG_RUNTIME_DIR. Since this location is not
86       persistent, the rest of the line instructs dconf how to store the
87       database persistently. A typical line is service-db:keyfile/user, which
88       tells dconf to synchronize the binary database with a plain text
89       keyfile in $XDG_CONFIG_HOME/dconf/user.txt. The synchronization is
90       bi-directional.
91
92       A "system-db" line specifies a system database. These databases are
93       found in /etc/dconf/db/. Again, the name of the file to open in that
94       directory is exactly as it is written in the profile and the file is
95       expected to be in the dconf database format.
96
97       If the DCONF_PROFILE environment variable is unset and the "user"
98       profile can not be opened, then the effect is as if the profile was
99       specified by this file:
100
101           user-db:user
102
103
104       That is, the user's personal database is consulted and there are no
105       system settings.
106

KEY FILES

108       To facilitate system configuration with a text editor, dconf can
109       populate databases from plain text keyfiles. For any given system
110       database, keyfiles can be placed into the /etc/dconf/db/database.d/
111       directory. The keyfiles contain groups of settings as follows:
112
113           # Some useful default settings for our site
114
115           [system/proxy/http]
116           host='172.16.0.1'
117           enabled=true
118
119           [org/gnome/desktop/background]
120           picture-uri='file:///usr/local/rupert-corp/company-wallpaper.jpeg'
121
122
123       After changing keyfiles, the database needs to be updated with the
124       dconf(1) tool.
125

LOCKS

127       System databases can contain 'locks' for keys. If a lock for a
128       particular key or subpath is installed into a database then no database
129       listed above that one in the profile will be able to modify any of the
130       affected settings. This can be used to enforce mandatory settings.
131
132       To add locks to a database, place text files in the
133       /etc/dconf/db/database.d/locks directory, where database is the name of
134       a system database, as specified in the profile. The files contain list
135       of keys to lock, on per line. Lines starting with a # are ignored. Here
136       is an example:
137
138           # prevent changes to the company wallpaper
139           /org/gnome/desktop/background/picture-uri
140
141
142       After changing locks, the database needs to be updated with the
143       dconf(1) tool.
144

PORTABILITY

146       dconf mostly targets Free Software operating systems. It will
147       theoretically run on Mac OS but there isn't much point to that (since
148       Mac OS applications want to store preferences in plist files). It is
149       not possible to use dconf on Windows because of the inability to rename
150       over a file that's still in use (which is what the dconf-service does
151       on every write).
152

API STABILITY

154       The dconf API is not particularly friendly, and is not guaranteed to be
155       stable. Because of this and the lack of portability, you almost
156       certainly want to use some sort of wrapper API around it. The wrapper
157       API used by GTK+ and GNOME applications is GSettings[1], which is
158       included as part of GLib. GSettings has backends for Windows (using the
159       registry) and Mac OS (using property lists) as well as its dconf
160       backend and is the proper API to use for graphical applications.
161

SEE ALSO

163       dconf-service(1), dconf-editor(1), dconf(1), GSettings[1]
164

NOTES

166        1. GSettings
167           http://developer.gnome.org/gio/stable/GSettings.html
168
169
170
171dconf                                                                 DCONF(7)
Impressum