Dconf: Difference between revisions

dconf
	A screenshot of dconf Editor running under Arch Linux
Developer(s)	The GNOME Project (Allison Lortie)
Initial release	September 16, 2009; 15 years ago
Stable release	0.40.0 / 13 March 2021; 3 years ago
Repository	gitlab.gnome.org/GNOME/dconf ;
Written in	C
Type	Configuration, settings management
License	GNU Lesser General Public License
Website	wiki.gnome.org/Projects/dconf

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 13:59, 14 May 2022

dconf is a low-level configuration system and settings management tool. Its main purpose is to provide a back end to GSettings on platforms that don't already have configuration storage systems. It depends on GLib. It is part of GNOME 3 and is a replacement for GConf.

Overview

dconf is a simple key-based configuration system. Keys exist in an unstructured database (but it is intended that keys that logically belong together are grouped together).

Change notification is supported.

Stacking of multiple configuration sources is supported. Mandatory keys are supported.

The stacking can be done at "mount points". For example, the global system configuration can be mounted under /system/ inside of each user's configuration space. A single configuration source may appear at multiple points in the hierarchy. For example, in addition to stacking over the normal keys at /user/, the system default keys may also appear at /default/ for inspection and modification by a system policy configuration utility.

PolicyKit integration is planned so that a normal user may temporarily gain the ability to, for example, write to the keys under /system/ (or /default/). This means that programs like the GNOME Display Manager configuration utility no longer have to be run as root.

Software architecture

Since a typical GNOME login consists of thousands of reads and ideally 0 writes, dconf is optimized for reads. Typically, reading a key from dconf involves zero system calls and zero context switches. This is achieved with a simple file format that doubles both as the storage format for data in dconf and as an IPC mechanism between the clients and the server.

Avoiding round trips and context switches is desirable in itself, but the real advantage^{[citation needed]} comes from allowing the I/O scheduler in the kernel to do a better job by saturating it with requests coming from all of the applications trying to read their keys (as opposed to a common configuration server serially requesting a single key at a time).

Having all of the keys in a single compact binary format also avoids the intense fragmentation problems currently experienced by the tree-of-directories-of-xml-files approach.

Writes are less optimized – they traverse the bus and are handled by a "writer" – a D-Bus service – in the ordinary way. Change notification is also handled by the writer. The reason for having a bus service at all is that because getting the clients to synchronize on writing would be very difficult.^{[citation needed]}

The writer service doesn't have to be activated until the first write operation is performed.

The service is completely stateless and can start and stop dynamically. The list of change notifications that an individual client is interested in is maintained by the bus daemon (as a D-Bus signal watch/match list).

dconf database

One dconf database consists of a single file in binary format, i.e. it is not a text-file. The format is defined as gvdb (GVariant Database file). It is a simple database file format that stores a mapping from strings to GVariant values in a way that is extremely efficient for lookups.

The GNOME database file for each user is by default ~/.config/dconf/user, a file expected to be in GVDB format.

GVariant

GVariant is a strongly typed value datatype. GVariant is a variant datatype; it can contain one or more values along with information about the type of the values.

A GVariant may contain simple types, like integers, or boolean values; or complex types, like an array of two strings, or a dictionary of key value pairs. A GVariant is also immutable: once it's been created, neither its type nor its content can be modified further. GVariant is useful whenever data needs to be serialized, for example when sending method parameters in DBus, or when saving settings using GSettings.

GVariant is part of GLib.

GSettings

The GSettings class provides a high-level API for application for storing and retrieving their own settings.

The utility program /usr/bin/gsettings is contained in libglib2.0-bin.

GSettings is part of GIO.^[2] which is part of GLib. libglib2.0-0

Documentation

A system administrators guide for dconf is available. Since version 0.2, dconf is licensed under the LGPL version 2.1 "or later".

History

Release history

Version	Release date	Significant changes
0.1	2009-09-18
0.2	2009-10-27
0.3	2010-05-25
0.4	2010-07-12
0.5	2010-09-15
0.6	2010-12-21
0.7	2011-05-09
0.8	2011-07-26
0.9	2011-09-19
0.10	2011-09-26
0.11	2012-03-19
0.12	2012-05-01
0.13	2012-08-20
0.14	2012-11-01
0.15	2013-02-11
0.16	2013-07-16
0.17	2013-09-16
0.18	2013-09-23
0.19	2014-03-17
0.20	2014-03-24	dconf compile: always write little endian
0.21	2014-07-22
0.22	2014-09-19
0.23	2015-03-16	split dconf-editor into a separate package
0.24	2015-03-23
0.25	2015-12-16
0.26	2016-03-23	libdbus-1 back-end removed; dconf now always uses GDBus
0.27	2017-10-17	Port to Meson build system (#784910)

References

^ "Release 0.40.0". 13 March 2021. Retrieved 10 April 2021.
^ "gio/gsettings.c · master · GNOME / GLib". GitLab. Retrieved 22 April 2018.

External links

[wikidata-ecb0aa1261fd6441e377bc28debcf3bcb9bf3910-v18-1] "Release 0.40.0". 13 March 2021. Retrieved 10 April 2021.

[2] "gio/gsettings.c · master · GNOME / GLib". GitLab. Retrieved 22 April 2018.

[1]

[2]

@@ Line 150: / Line 150: @@
 | 0.27 || 2017-10-17 || Port to [[Meson build system]] (#784910)
 |}
-==Alternatives==
-[https://www.libelektra.org Elektra] stores preferences in customizable configuration files, usually in text form such as INI, XML, or JSON. In contrast to dconf, the system administrator chooses which configuration settings should be placed in which file (and in which format) by mounting.
-[[Inkscape]] stores preferences in one XML file located at <code>~/.config/Inkscape/preferences.xml</code> (on Linux) and <code>%APPDATA%\inkscape\preferences.xml</code> (on Windows).<ref>{{cite web
- | url   = https://wiki.inkscape.org/wiki/index.php/Preferences_subsystem
- | title = Inkscape Wiki: preferences subsystem}}</ref>
-[[GIMP]] stores them in one file at <code>/etc/gimp/2.0/gimprc</code> and another one at <code>$HOME/.gimp-2.8/gimprc</code> overwriting the global settings if so.
-KDE doesn't use dconf. In KDE, settings are stored in simple text files located at <code>~/.kde/share/config/&lt;appname&gt;rc</code> or <code>.kde/config/&lt;appname&gt;rc</code>, rather than a database. The GUI for changing these settings is systemsettings, although individual application settings are usually set within the application.
-Most Windows applications still store their user settings in individual .ini (initialization) files spread across the disk. They additionally use the [[Windows Registry]] to store information which might be of interest for other software. For such programs the Windows Registry acts rather as a [[bulletin board]], than as a user settings system. When such an application is removed (uninstalled), it is also rather the default than the exception, that its registry entries are not being purged and remain in the database. The Windows Registry is rather extensive and with time becomes more and more bloated. Without the user knowing exactly what to look for, a simple search can be compared to finding the "needle in a haystack." Therefore, with regards to purpose and volume, dconf cannot be compared to the Windows Registry. In fact the only commonality between dconf and the Windows Registry is the usage of a database.
-The Windows Registry is structured into hives. Each hive is kept in a separate file (in the directory <code>C:\Windows\system32\config\</code> of the system and boot partition). When a Windows system boots, the bootstrap loader (the same that loads the kernel and other boot files, such as boot drivers, from the boot partition) loads the SYSTEM file into memory. A great deal of crucial information is kept in the SYSTEM hive, including information about what drivers to use with what devices, what software to run initially, and many parameters governing the operation of the system. The conventions for the arrangement of configuration information are poorly defined.
 ==References==