Ubuntu – Shouldn’t dconf-editor and gsettings access the same database

dconfgnomegsettingssystem-settingsunity

This is a basically 'academic' question — to try to understand better the configuration system innards.

I understand that the dconf system is the new configuration system in gnome3 that has replaced the (deprecated) gconf; this is quite clear from Gconf, Dconf, Gsettings and the relationship between them.

It seemed to me that the programs gsettings and dconf-editor where just two different way to access the same dconf database, which is corroborated in
What is dconf, what is its function, and how do I use it?

EDIT: I discovered that someone noticed it as a difference in case in some schema name, see here — Are dconf schema names case-sensitive?; but it seems that the differences are not restricted to that. In one of the answer there is an example of mismatch, but I didn't find an explication of why.

But lately I discovered that the keys accessible from gsettings and dconf-editor are not the same. For example, settings for vino are in dconf-editor under org.gnome.desktop.remote-access (see screenshot below) while in gsettings they are under org.gnome.Vino. There is some documentation that explain the difference?

In gsettings:

(0)samsung-romano:~/tmp/try% gsettings list-recursively org.gnome.Vino
org.gnome.Vino alternative-port uint16 5900
org.gnome.Vino authentication-methods ['none']
org.gnome.Vino disable-background false
[...]

and:

(0)samsung-romano:~/tmp/try% gsettings list-recursively org.gnome.desktop.remote-access
No such schema 'org.gnome.desktop.remote-access'

But in dconf-editor:

dconf-editor

Best Answer

  • dconf-editor uses schema path to show settings data tree. Same structure used to store data in GVariant database.

  • gsettings (from glib-2.0) uses schema id to show/get settings data. Same way as any other application should do which uses GSetttings API.

  • It's up to the application developer to set both as he/she would like. (with some restriction for canonical naming). So path could be different than id but most application developers prefer to use identical word series/combination. Some don't preserve same capitalization. Example Tracker project from Gnome

    <schema id="org.freedesktop.Tracker.Miner" path="/org/freedesktop/tracker/miner/" />
    

    In addition to that, some alternative applications share same settings which belong to the Gnome desktop. Example: input-sources


  • First, Apps should not mess with dconf

    Introduction from dconf project page:

    dconf is a low-level configuration system. Its main purpose is to provide a backend to GSettings on platforms that don't already have configuration storage systems.

  • Where's the data stored? (Ref: https://wiki.gnome.org/Projects/dconf/SystemAdministrators)

    A profile is a list of configuration databases. What it seems that Gnome & Unity use same profile.

    $ cat /etc/dconf/profile/gdm
    user-db:user
    system-db:gdm
    
    1. user-db:user: First database in the profile is read-write rw and it is created in the user's home directory.

      $ file ~/.config/dconf/user
      /home/sneetsher/.config/dconf/user: GVariant Database file, version 0
      
    2. system-db:gdm: read-only

      $ file /etc/dconf/db/gdm
      /etc/dconf/db/gdm: GVariant Database file, version 0
      

      dconf could bind a text style store in addition to GVariant Database from db.d/* folder. Example (Notice file path, so it is a part of system-db:gdm):

       $ cat /etc/dconf/db/gdm.d/00-upstream-settings
      
       # This file is part of the GDM packaging and should not be changed.
       #
       # Instead create your own file next to it with a higher numbered prefix,
       # and run
       #
       #       dconf update
       #
      
       [org/gnome/desktop/a11y/keyboard]
       enable=true
      
       [org/gnome/desktop/background]
       show-desktop-icons=false
       ...
      
  • Schema Files: Relation between schema id & schema path (*.gschema.xml)

    What is the schema XML file in the data/glib-2.0 folder of my Quickly application? by trent shows a nice example of using GSettings API in a Quickly application, and his conclusion based on his experience.

    Back to Vino. Each application that uses GSsettings should define its schema's and should store/install them in /usr/share/glib-2.0/schemas/ (It's a glib directory):

    $ dpkg -L vino | grep -i glib-2.0
    /usr/share/glib-2.0
    /usr/share/glib-2.0/schemas
    /usr/share/glib-2.0/schemas/org.gnome.Vino.enums.xml
    /usr/share/glib-2.0/schemas/org.gnome.Vino.gschema.xml
    
    $ more /usr/share/glib-2.0/schemas/org.gnome.Vino.gschema.xml
    <schemalist>
      <schema id='org.gnome.Vino' path='/org/gnome/desktop/remote-access/'>
        <key name='enabled' type='b'>
          <summary>Enable remote access to the desktop</summary>
          <description>
            If true, allows remote access to the desktop via the RFB
            protocol. Users on remote machines may then connect to the
            desktop using a VNC viewer.
          </description>
          <default>false</default>
        </key>
    
        <key name='prompt-enabled' type='b'>
          <summary>Prompt the user before completing a connection</summary>
          <description>
            If true, remote users accessing the desktop are not allowed
            access until the user on the host machine approves the
            connection. Recommended especially when access is not password
            protected.
          </description>
          <default>true</default>
        </key>
    ...
    

    If you noticed, The schema is defined with an id and a path. The schema file name follows the id value.

    <schema id='org.gnome.Vino' path='/org/gnome/desktop/remote-access/'>
    
  • *.enums.xml files are for custom enumeration declaration, to be used as new data types in *.gschema.xml with same schema id.

    $ cat /usr/share/glib-2.0/schemas/org.gnome.Vino.enums.xml
    <!-- Generated data (by glib-mkenums) -->
    
    <schemalist>
      <enum id='org.gnome.Vino.VinoIconVisibility'>
        <value nick='never' value='0'/>
        <value nick='always' value='1'/>
        <value nick='client' value='2'/>
      </enum>
    </schemalist>
    
    <!-- Generated data ends here -->
    
    $ gsettings range org.gnome.Vino icon-visibility
    enum
    'never'
    'always'
    'client'
    
    $ gsettings get org.gnome.Vino icon-visibility
    'client'
    
  • Compiling Schema's (Ref: Playing with dconf and gnome-tweak-tool)

    As part of the installation process (it has a dpkg trigger), schema's are compiled with glib-compile-schemas tool (from glib)

    sudo glib-compile-schemas /usr/share/glib-2.0/schemas
    

    *.gschema.xml will be compiled to a binary file /usr/share/glib-2.0/schemas/gschemas.compiled

  • Vendor Override Files (*.gschema.override)

    In addition to schema files, glib-compile-schemas reads vendor override files, which are key files that can override default values for keys in the schemas (Ref: man glib-compile-schemas). They contain the changes done by Ubuntu distribution to override upstream schema defaults.

    $ ls /usr/share/glib-2.0/schemas/*.gschema.override
    /usr/share/glib-2.0/schemas/10_compiz-gnome.gschema.override
    /usr/share/glib-2.0/schemas/10_desktop-base.gschema.override
    /usr/share/glib-2.0/schemas/10_evolution-common.gschema.override
    /usr/share/glib-2.0/schemas/10_gnome-settings-daemon.gschema.override
    /usr/share/glib-2.0/schemas/10_gnome-shell.gschema.override
    /usr/share/glib-2.0/schemas/10_gnome-system-log.gschema.override
    /usr/share/glib-2.0/schemas/10_gsettings-desktop-schemas.gschema.override
    /usr/share/glib-2.0/schemas/10_libgtk-3-common.gschema.override
    /usr/share/glib-2.0/schemas/10_ubuntu-settings.gschema.override
    /usr/share/glib-2.0/schemas/20_ubuntu-gnome-default-settings.gschema.override
    
    $ cat /usr/share/glib-2.0/schemas/10_gnome-settings-daemon.gschema.override
    [org.gnome.desktop.wm.keybindings]
    switch-input-source=['<Super>space']
    switch-input-source-backward=['<Shift><Super>space']
    

    Example of override files use, See How to customize the Ubuntu Live CD? (5. Customization 2: Backgrounds and Themes).

  • Lock files

    Currently, dconf supports only per-key locking, no sub-path lock. User defined values will still be stored in user-db but will have no effect on applications. dconf/gsettings returns default values instead for those locked keys. Lock files are stored in db.d/locks/. Example:

    $ cat /etc/dconf/db/gdm.d/locks/00-upstream-settings-locks 
    /org/gnome/desktop/a11y/keyboard/enable
    /org/gnome/desktop/background/show-desktop-icons
    /org/gnome/desktop/lockdown/disable-application-handlers
    /org/gnome/desktop/lockdown/disable-command-line
    /org/gnome/desktop/lockdown/disable-lock-screen
    /org/gnome/desktop/lockdown/disable-log-out
    /org/gnome/desktop/lockdown/disable-printing
    /org/gnome/desktop/lockdown/disable-print-setup
    /org/gnome/desktop/lockdown/disable-save-to-disk
    /org/gnome/desktop/lockdown/disable-user-switching
    ...
    

    After locks modification, to be effective run:

    sudo dconf update
    

    A good showcase: dconf Settings: defaults and locks

  • Changing Global Settings

    The default for gsettings/dconf-editor is to edit the user-db. To change system-db, write a new override file and recompile schema's.

    I couldn't get this to work:

    sudo su gdm -c 'gsettings ...'
    

    neither the other answers here Set Default/Global Gnome Preferences (Gnome 3), may be that was for an old release.