dconf-editor和gsettings不应该访问同一个数据库吗？

Question

dconf-editor和gsettings不应该访问同一个数据库吗？

41

这只是一个基本上的“学术”问题——试图更好地理解配置系统内部。我知道 dconf 系统是 gnome3 中取代（不再推荐使用的）gconf 的新配置系统；从 Gconf，Dconf，Gsettings 和它们之间的关系这一点非常清楚。在我看来，程序 gsettings 和 dconf-editor 只是访问相同的 dconf 数据库的两种不同方式，这在 dconf 是什么，它有什么功能，我该如何使用它？中得到了证实。编辑：我发现有人注意到了一些模式名称的大小写差异，可以在这里看到 --- dconf 模式名称是否区分大小写？；但似乎这些差异并不仅限于此。在其中一个答案中有一个不匹配的示例，但我没有找到关于为什么的解释。但是最近我发现从 gsettings 和 dconf-editor 可以访问的键不同。例如，vino 的设置在 dconf-editor 中位于 org.gnome.desktop.remote-access 下（见下面的截图），而在 gsettings 中它们位于 org.gnome.Vino 下。有没有一些文档可以解释这个差异？在 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
[...]

和：

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

但在 dconf-editor 中：

dconf-editor

- Rmano

1个回答

- user.dz · Accepted Answer

dconf-editor 使用 schema path 来显示设置数据树。相同的结构用于在 GVariant 数据库中存储数据。
gsettings（来自 glib-2.0）使用 schema id 来显示/获取设置数据。与使用 GSettings API 的任何其他应用程序一样。
应用程序开发人员可以根据自己的喜好设置这两个值（对于规范命名有一些限制）。因此，path 可能与 id 不同，但大多数应用程序开发人员更喜欢使用相同的词序列/组合。有些人不保留相同的大小写。例如 Gnome 的 Tracker 项目
```
<schema id="org.freedesktop.Tracker.Miner" path="/org/freedesktop/tracker/miner/" />
```
除此之外，一些替代应用程序共享属于 Gnome 桌面的相同设置。例如：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

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
```

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.