Gconf, Dconf, Gsettings и отношения между ними

Я пытаюсь понять, как работают Gconf, Dconf и Gsettings и каковы отношения между ними.

Все, что я знаю, это:

  • Gconf - база данных на основе XML (бэкэнд-система). Старшая
  • Dconf - База данных на основе BLOB (бэкэнд-система). Более новый.
  • Gsettings - инструмент CLI для редактирования настроек. Похоже, он работает только с Dconf (хотя я где-то видел, что он может работать с Gconf).

Я знаю, что для Gconf есть GUI - Gconf-редактор, а для Dconf - Dconf-редактор.

Так:

  1. Какая бэкэнд-система используется чаще - Dconf или Gconf?
  2. Gsettings работает с ними обоими? И почему он не показывает все схемы Dconf?
  3. Где Dconf сохраняет свои данные?
Источник

3 ответа

Решение

GConf устарел. Это более старый API и система конфигурации GNOME 2.x, и в новых версиях его заменили DConf/GSettings. Тем не менее, некоторые приложения все еще используют его.

GSettings - это GLib-реализация DConf, которая хранит свои данные в двоичной базе данных.

gsettings инструмент командной строки - это просто инструмент для доступа или изменения настроек через GSettings API, так же, как старый gconftool инструмент командной строки для GConf.

Источник

Dconf - это хранилище данных, предназначенное для хранения конфигурации. Это замена для Gconf, который был использован для той же цели. В конце концов, никакие программы больше не должны зависеть от Gconf.

Gsettings - это библиотека разработки, используемая для чтения и записи в бэкэнд хранилища конфигурации. В Linux он использует Dconf, но в Windows он использует реестр, а в OS X он использует собственное хранилище данных.

Разработчикам приложений и конечным пользователям рекомендуется использовать Gsettings, а не Dconf напрямую.

Смотрите также:

Источник

Игнорирование GConf здесь, потому что оно устарело. TLDR: используйте .

не знает схем, поэтому слеп к значениям по умолчанию

из man dconf(1):

Программа dconf может выполнять различные операции с базой данных dconf, такие как чтение или запись отдельных значений или целых каталогов. Этот инструмент работает с dconf напрямую, без использования информации о схеме gsettings. Следовательно, он не может выполнять проверки типов и согласованности значений. Утилита gsettings(1) является альтернативой, если такие проверки необходимы.

Меня не очень волнуют «проверки типа и согласованности».
На практике я вижу более важное отличие — dconfвидит только те настройки, которые я явно установил. Пример нетронутых настроек:

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

Здесь dconf read -dутверждает, что читает значения по умолчанию, но на практике ничего не делает для меня?

Я все еще могу написать это (вслепую), даже если для того же значения 1.0, что и по умолчанию, и тогда dconf его увидит:

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

Более того, я могу хранить любой ключ, который сам придумаю! Таким образом, он функционирует как тупая хеш-таблица явно заданных значений, и resetпросто удаляет запись:

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

использует данные схемы

Что ж, это имеет смысл. я использовал locate --regexp org.gnome.desktop.interfaceи получил пару xml-файлов (может быть, не тот), а файлы схемы действительно содержат по умолчанию:

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

Так gsettingsобъединяет фактически установленные значения со значениями по умолчанию.

Вот почему вместо одного пути он принимает два аргумента, например. gsettings read SCHEMA[:PATH] KEY— поскольку он начинается со схемы, сопоставляет ее с путем dconf (см. gsettings list-schemas --print-pathsно принимает необязательный PATH для перемещаемых схем), а затем накладывает измененные значения из dconf.

Он также может вывести некоторую информацию о схеме:

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

но несколько разочаровывающе, я не вижу никакого способа просто прочитать значение по умолчанию (если установлено значение) и не различать, оставлены ли настройки по умолчанию или явно установлено одно и то же значение.

dconf-editorтакже использует данные схемы

Несмотря на свое название, dconf-editor показывает как измененные настройки, так и настройки по умолчанию, включая те, которые установлены по умолчанию, и те, которые установлены явно:

и полностью осведомлен о схеме информации:

Источник
Другие вопросы по тегам