Shouldn't dconf-editor and gsettings access the same database?

Question

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:

Solution

• 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.

Comments

[user.dz]

@Rmano, I had a curiosity me too to learn about it. Thank you alot.

[Anatoli]

Could you please explain how to define user-specific settings using dconf (say, I need to deploy one set of settings for one user (copying necessary files to his/her ~/.config/dconf dir just after creating the account) and another for the second user, how?)? AFAIK, the "text style store" is only supported for system-wide settings, isn't it? Is there any way to dump only user settings (e.g. those in ~/.config/dconf/user)? I know about "dconf dump /", but this is for the entire user DB, including the system defaults. The documentation is extremely incomplete.

[user.dz]

@Anatoli, Yeah, text store only works for system wide database. Actually dconf dump / dumps all user altered entries, it does not include entries never changed or have been reset. (for example, it includes the entries have been changed or set even their values are same as default). See askubuntu.com/q/420527/26246 . Also is not the whole DB, you can set the path. ex: dconf dump /com/

[Anatoli]

@user.dz, thanks for the clarification. So the only way to configure user-specific settings is by creating the 'user' GVDB-binary file on another clean account with necessary settings and then to copy it to the .config/dconf folder? AFAIK, there's no way to use dconf load / < file without logging in as the user.

[user.dz]

@Anatoli, Yes that one way. May be easier way to alter other user setting without logging how ever you need his password or root power (security rule). This should work sudo su username2 -c "dconf load / < file"

[Anatoli]

@user.dz, thanks. Actually, as I was suspecting, the target user's dbus session is needed for this command, so a simple su username -c "dconf load /" won't suffice. But fortunately, there's a simple way to accomplish this: the dconf load should be prefixed with dbus-launch, i.e.: sudo su username2 -c "dbus-launch dconf load / < file". The only problem after this is to kill 2 newly created processes: dbus-daemon & dconf-service, but that's manageable (their parent is the upstart process of the user invoking the sudo command).

[WinEunuuchs2Unix]

How can you have duplicate and triplicate settings returned by gsettings list-recursively? askubuntu.com/questions/1090244/…