Используя довольно простую схему, с единственным булевым ключом, я не смог заставить dconf-редактора признавать, что ключ на самом деле определяется где угодно и когда я перешел к ключу от dconf-редактора, я получаю предупреждение, что ключ не имеет никакой схемы и предлагает, чтобы я удалил его.
gsettings (инструмент командной строки) позволяют мне извлекать описание очень хорошо, указывая, что схема установлена правильно. Управление и чтение ключа через gsettings, кажется, хорошо работают, и результат действительно обнаруживается в dconf-editor
в режиме реального времени.
Моя схема:
<?xml version="1.0" encoding="UTF-8"?>
<schemalist gettext-domain="example-schema">
<schema
id="org.example.schema"
path="/org/example/schema/"
>
<key name="boolean_value" type="b">
<default>false</default>
<summary>A boolean value</summary>
<description>A value that may be either true or false</description>
</key>
</schema>
</schemalist>
Я поместил схему в /usr/share/glib-2.0/schemas
и затем выполненный glib-compile-schemas .
когда внутри /usr/ share/glib-2.0/schemas
. После этого когда я запрашиваю с gsettings
, схема действительно обнаруживается, и я могу получить доступ boolean_value
ключ.
Я разрабатываю это на Fedora 31 (существует, не Спрашивают Fedora), с dconf-редактором 3.34.4 и версией 2.62.5 gsettings.
dconf-редактор на самом деле не делает никакого надлежащего самоанализа базы данных, вместо этого это отображается между известными путями и идентификатор и использование, что, чтобы выяснить, как описать ключ. Этот список является hardcoded в программу и требует, чтобы перекомпилировать обновило.
Результат состоит в том, что, если Ваша схема не находится в том списке, dconf-редактор не будет знать об этом; если Вы хотите, чтобы Ваш пользователь получил хорошую обратную связь от dconf-редактора, необходимо изменить их версию программы, скомпилировать ее и затем установить ее.