Sollten dconf-editor und gsettings nicht auf dieselbe Datenbank zugreifen?

Question

dconf-editorwird verwendet schema path, um den Einstellungsdatenbaum anzuzeigen. Dieselbe Struktur wird zum Speichern von Daten in der GVariant-Datenbank verwendet.
gsettings(ab glib-2.0) wird verwendet, schema idum Einstellungsdaten anzuzeigen/abzurufen. Genauso wie jede andere Anwendung, die die GSetttings-API verwendet.
Es liegt am Anwendungsentwickler, beides nach Wunsch festzulegen (mit einigen Einschränkungen für die kanonische Benennung). Es pathkönnte also anders sein, idaber die meisten Anwendungsentwickler bevorzugen die Verwendung identischer Wortreihen/-kombinationen. Einige behalten die Groß- und Kleinschreibung nicht bei. BeispielTracker-Projekt von Gnome
```
<schema id="org.freedesktop.Tracker.Miner" path="/org/freedesktop/tracker/miner/" />
```
Darüber hinaus verwenden einige alternative Anwendungen dieselben Einstellungen, die zum Gnome-Desktop gehören. Beispiel:input-sources

Erste,Apps sollten nicht mitdconf

Einführung vondconfProjektseite:

dconfist ein Low-Level-Konfigurationssystem. Sein Hauptzweck besteht darin, ein Backend für GSettings auf Plattformen bereitzustellen, die noch keine Konfigurationsspeichersysteme haben.

Wo werden die Daten gespeichert?(Referenz:https://wiki.gnome.org/Projects/dconf/SystemAdministrators)

Ein Profil ist eine Liste von Konfigurationsdatenbanken. Es scheint, dass Gnome und Unity dasselbe Profil verwenden.

$ cat /etc/dconf/profile/gdm
user-db:user
system-db:gdm

user-db:user: Die erste Datenbank im Profil ist lese-/schreibbar rwund wird im Home-Verzeichnis des Benutzers erstellt.
```
$ file ~/.config/dconf/user
/home/sneetsher/.config/dconf/user: GVariant Database file, version 0
```

system-db:gdm: schreibgeschützt

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

dconfkönnte zusätzlich zur GVariant-Datenbank aus dem Ordner einen Textstilspeicher binden db.d/*. Beispiel (Beachten Sie den Dateipfad, es ist also ein Teil von 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
 ...

Schemadateien: Beziehung zwischen schema id&schema path ( *.gschema.xml)

Was ist die Schema-XML-Datei im Ordner data/glib-2.0 meiner Quickly-Anwendung?vontrentzeigt ein schönes Beispiel für die Verwendung der GSettings-API in einer Quickly-Anwendung und seine Schlussfolgerung basierend auf seinen Erfahrungen.

Zurück zu Vino. Jede Anwendung, die GSsettings verwendet, sollte ihre Schemata definieren und sie hier speichern/installieren /usr/share/glib-2.0/schemas/(es ist ein Glib-Verzeichnis):

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

idWie Sie vielleicht bemerkt haben, ist das Schema mit einem und einem definiert path. Der Schemadateiname folgt dem idWert.

<schema id='org.gnome.Vino' path='/org/gnome/desktop/remote-access/'>

*.enums.xmlDateien dienen zur benutzerdefinierten Aufzählungsdeklaration und sollen als neue Datentypen *.gschema.xmlmit denselben verwendet werden 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'

Kompilieren von Schemas(Referenz:Spielen mit dconf und Gnome-Tweak-Tool)

Als Teil des Installationsprozesses (es verfügt über einen Dpkg-Trigger) werden Schemata mit glib-compile-schemasdem Tool (von glib) kompiliert.
```
sudo glib-compile-schemas /usr/share/glib-2.0/schemas
```
*.gschema.xmlwird in eine Binärdatei kompiliert/usr/share/glib-2.0/schemas/gschemas.compiled

Vendor-Override-Dateien( *.gschema.override)

Zusätzlich zu den Schemadateien glib-compile-schemasliestLieferantenüberschreibungDateien, bei denen es sich um Schlüsseldateien handelt, die Standardwerte für Schlüssel in den Schemata überschreiben können (Ref:man glib-compile-schemas). Sie enthalten die von der Ubuntu-Distribution vorgenommenen Änderungen, um die Schemastandards der Upstream-Distribution zu überschreiben.

$ 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']

Beispiel für die Verwendung von Override-Dateien, sieheWie passe ich die Ubuntu Live-CD an?(5. Anpassung 2: Hintergründe und Themen).

Dateien sperren

Derzeit unterstützt dconf nur die Sperrung einzelner Schlüssel, keine Sperrung von Unterpfaden. Benutzerdefinierte Werte werden weiterhin in gespeichert, user-dbhaben aber keine Auswirkung auf Anwendungen. dconf/gsettings gibt stattdessen Standardwerte für diese gesperrten Schlüssel zurück. Sperrdateien werden in gespeichert db.d/locks/. Beispiel:

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

Führen Sie nach der Änderung der Sperren Folgendes aus, damit sie wirksam wird:

sudo dconf update

Ein gutes Beispiel:dconf-Einstellungen: Standardeinstellungen und Sperren

Globale Einstellungen ändern

Die Vorgabe für gsettings/ dconf-editorist die Bearbeitung von user-db. Um dies zu ändern system-db, schreiben Sie eine neue Override-Datei und kompilieren Sie die Schemata neu.

Ich habe es nicht geschafft, das hier zum Laufen zu bringen:
```
sudo su gdm -c 'gsettings ...'
```
weder die anderen Antworten hierStandardmäßige/globale Gnome-Einstellungen festlegen (Gnome 3), möglicherweise war das für eine alte Version.

Answer 1

dconf-editorwird verwendet schema path, um den Einstellungsdatenbaum anzuzeigen. Dieselbe Struktur wird zum Speichern von Daten in der GVariant-Datenbank verwendet.
gsettings(ab glib-2.0) wird verwendet, schema idum Einstellungsdaten anzuzeigen/abzurufen. Genauso wie jede andere Anwendung, die die GSetttings-API verwendet.
Es liegt am Anwendungsentwickler, beides nach Wunsch festzulegen (mit einigen Einschränkungen für die kanonische Benennung). Es pathkönnte also anders sein, idaber die meisten Anwendungsentwickler bevorzugen die Verwendung identischer Wortreihen/-kombinationen. Einige behalten die Groß- und Kleinschreibung nicht bei. BeispielTracker-Projekt von Gnome
```
<schema id="org.freedesktop.Tracker.Miner" path="/org/freedesktop/tracker/miner/" />
```
Darüber hinaus verwenden einige alternative Anwendungen dieselben Einstellungen, die zum Gnome-Desktop gehören. Beispiel:input-sources

Erste,Apps sollten nicht mitdconf

Einführung vondconfProjektseite:

dconfist ein Low-Level-Konfigurationssystem. Sein Hauptzweck besteht darin, ein Backend für GSettings auf Plattformen bereitzustellen, die noch keine Konfigurationsspeichersysteme haben.