91

I'm trying to understand how Gconf, Dconf and Gsettings works and what the relationship is between them.

All I know is:

  • Gconf - XML based database (backend system). The older one.
  • Dconf - BLOB based database (backend system). The newer one.
  • Gsettings - CLI tool to edit settings. Looks like it works only with Dconf (although I saw somewhere that it might work with Gconf).

I know that for Gconf there is a GUI - Gconf-editor, and for Dconf - Dconf-editor.

So:

  1. Which backend system is more often used - Dconf or Gconf?
  2. Gsettings works with both of them? And why doesn't it show all Dconf schemas?
  3. Where does Dconf save its data?
1
  • 1
    I would be particularly interested in which settings are handled by which tool (dconf or gsettings) and why there are differences?
    – jpp1
    Sep 21, 2015 at 15:06

3 Answers 3

65

Dconf is a data store designed for storing configuration. It is the replacement for Gconf, which was used for the same purpose. Eventually, no programs should depend on Gconf any more.

Gsettings is a development library used to read and write to a configuration store backend. On Linux, it uses Dconf, but on Windows, it uses the registry, and on OS X, it uses a native data store. (The gsettings command on the CLI uses this library.)

Application developers and end-users are recommended to use Gsettings, not Dconf directly.

See also:

4
  • gsettings is a CLI tool though, like OP mentions. I think they want to know whether they should use that, or dconf (or gconf), basically.
    – Victor
    Oct 7, 2021 at 7:41
  • @Victor I'm not sure I understand your comment. Like I said, application developers and end-users are recommended to use Gsettings, not dconf or gconf.
    – Flimm
    Oct 7, 2021 at 8:26
  • OP is specifically asking about "Gsettings - CLI tool to edit settings." That's the context. Not about the library.
    – Victor
    Oct 7, 2021 at 8:48
  • 1
    @Victor I've edited the answer post to clarify that gsettings the CLI command uses Gsettings the library. Both application developers and end-users are recommended to use Gsettings (either as a library, or as a command on the CLI).
    – Flimm
    Oct 7, 2021 at 8:51
46

GConf is obsolete. It is the older GNOME 2.x configuration API and system, and has been replaced by DConf/GSettings in newer versions. However, some applications still use it.

GSettings is a GLib implementation of DConf, which stores its data in a binary database.

The gsettings command line tool is simply a tool to access or modify settings via the GSettings API, in the same way that the older gconftool command line tool is for GConf.

13
  • 1
    Is GSettings works with GConf also?
    – idgar
    Jan 31, 2013 at 18:05
  • 4
    No, GSettings is an implementation of the DConf spec. The command line tool doesn't work with gconf. There are however, some compatibility layers currently in use on Ubuntu, where changing a setting in gsettings or gconf, will result in the change being propagated to the other. This isn't common though, and not something to rely on.
    – dobey
    Jan 31, 2013 at 18:39
  • another thing,i saw somewhere that GSettings works with configuration files. is there something about it? and why does GSettings doesn't show the same schemas as DConf-editor?
    – idgar
    Feb 3, 2013 at 14:30
  • 2
    The interesting part to know would be which settings are managed by which tool? The keys which are present when using dconf or dconf-editor are different from those accessible with gsettings, for example there is a key /com/canonical/unity/always-show-menus accessible via dconf but there is no equivalent key accessible via gsettings in Ubuntu 15.04.
    – jpp1
    Sep 21, 2015 at 15:04
  • 1
    @dobey: thank you for helping with this. What I am really after is though: how does the mapping between the key I have to use in dconf and the key I have to use with gsettings work? If I know one, is there an algorithmic way to find the other? In my concrete case I was given /com/canonical/unity/always-show-menus -- now how would I find the appropriate key for gsettings? If both use the same underlying data, should there not be a logical mapping? Or am I still missing something?
    – jpp1
    Sep 23, 2015 at 11:52
2

Ignoring GConf here because it's obsolete. TLDR: use gsettings.

dconf is ignorant of schemas, so is blind to defaults

from man dconf (1):

The dconf program can perform various operations on a dconf database, such as reading or writing individual values or entire directories. This tool operates on dconf directly, without using gsettings schema information. Therefore, it cannot perform type and consistency checks on values. The gsettings(1) utility is an alternative if such checks are needed.

I don't care that much about "type and consistency checks".
In practice, I see a more important difference — dconf only sees settings that I explicitly set. Example of untouched settings:

> gsettings list-recursively org.gnome.desktop.interface | grep scaling
org.gnome.desktop.interface text-scaling-factor 1.0
org.gnome.desktop.interface scaling-factor uint32 0

> gsettings list-schemas --print-paths | grep org.gnome.desktop.interface
org.gnome.desktop.interface /org/gnome/desktop/interface/

> dconf dump /org/gnome/desktop/interface/ | grep scaling
> dconf list /org/gnome/desktop/interface/ | grep scaling
> dconf read /org/gnome/desktop/interface/text-scaling-factor
> dconf read -d /org/gnome/desktop/interface/text-scaling-factor
>

Here dconf read -d claims it reads default values, but in practice does nothing for me? 😕

I can still write it (blindly), even if to same 1.0 value as default and then dconf sees it:

> dconf write /org/gnome/desktop/interface/text-scaling-factor 1.0
> dconf dump /org/gnome/desktop/interface/ | grep scaling-factor
text-scaling-factor=1.0
> dconf read /org/gnome/desktop/interface/text-scaling-factor
1.0
> dconf read -d /org/gnome/desktop/interface/text-scaling-factor
>

Moreover, I can store any key I make up! So it functions like a dumb hash table of exlicitly set values, and reset just deletes the entry:

> dconf write /org/gnome/desktop/interface/foo 123
> dconf dump /org/gnome/desktop/interface/ | grep foo
foo=123
> dconf reset /org/gnome/desktop/interface/foo
> dconf dump /org/gnome/desktop/interface/ | grep foo
>

gsettings uses schema data

Well, that makes sense. I used locate --regexp org.gnome.desktop.interface and got a couple xml files (maybe not the right one), and the schema files do contain the default:

      <key name="text-scaling-factor" type="d">
        <range min="0.5" max="3.0"/>
        <default>1.0</default>
        <summary>Text scaling factor</summary>
        <description>
          Factor used to enlarge or reduce text display, without c>
        </description>
      </key>

So gsettings combines the actually set values with defaults.

💡 That's why instead of single path it takes two arguments eg. gsettings read SCHEMA[:PATH] KEY — because it starts from the schema, maps it to dconf path (see gsettings list-schemas --print-paths but takes optional PATH for relocatable schemas), and then overlays the modified values from dconf.

It can also dump some schema info:

> gsettings describe org.gnome.desktop.interface text-scaling-factor
Factor used to enlarge or reduce text display, without changing font size.

but somewhat disappointingly, I don't see any way to just read the default (if a value is set), nor distinguish whether a settings is left at default or explicitly set to same value.

dconf-editor also uses schema data

Despite its name, dconf-editor does show both modified and default settings, including which are default and which are explicitly set:

screenshot from dconf-editor /org/gnome/desktop/interface/

and is fully aware of schema info:

screenshot from dconf-editor /org/gnome/desktop/interface/text-scaling-factor

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.