docs: Move the GSettings SECTIONs

Move them to the struct docs.

Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>

Helps: #3037
This commit is contained in:
Philip Withnall 2023-11-02 16:22:47 +00:00
parent 8c3e0aa406
commit c16c639729
4 changed files with 119 additions and 146 deletions

View File

@ -37,116 +37,115 @@
#include "strinfo.c"
/**
* SECTION:gsettings
* @short_description: High-level API for application settings
* @include: gio/gio.h
* GSettings:
*
* The #GSettings class provides a convenient API for storing and retrieving
* The `GSettings` class provides a convenient API for storing and retrieving
* application settings.
*
* Reads and writes can be considered to be non-blocking. Reading
* settings with #GSettings is typically extremely fast: on
* settings with `GSettings` is typically extremely fast: on
* approximately the same order of magnitude (but slower than) a
* #GHashTable lookup. Writing settings is also extremely fast in terms
* of time to return to your application, but can be extremely expensive
* [struct@GLib.HashTable] lookup. Writing settings is also extremely fast in
* terms of time to return to your application, but can be extremely expensive
* for other threads and other processes. Many settings backends
* (including dconf) have lazy initialisation which means in the common
* case of the user using their computer without modifying any settings
* a lot of work can be avoided. For dconf, the D-Bus service doesn't
* a lot of work can be avoided. For dconf, the D-Bus service doesnt
* even need to be started in this case. For this reason, you should
* only ever modify #GSettings keys in response to explicit user action.
* only ever modify `GSettings` keys in response to explicit user action.
* Particular care should be paid to ensure that modifications are not
* made during startup -- for example, when setting the initial value
* of preferences widgets. The built-in g_settings_bind() functionality
* is careful not to write settings in response to notify signals as a
* result of modifications that it makes to widgets.
* made during startup for example, when setting the initial value
* of preferences widgets. The built-in [method@Gio.Settings.bind]
* functionality is careful not to write settings in response to notify signals
* as a result of modifications that it makes to widgets.
*
* When creating a GSettings instance, you have to specify a schema
* When creating a `GSettings` instance, you have to specify a schema
* that describes the keys in your settings and their types and default
* values, as well as some other information.
*
* Normally, a schema has a fixed path that determines where the settings
* are stored in the conceptual global tree of settings. However, schemas
* can also be '[relocatable][gsettings-relocatable]', i.e. not equipped with
* can also be [relocatable](#relocatable-schemas), i.e. not equipped with
* a fixed path. This is
* useful e.g. when the schema describes an 'account', and you want to be
* useful e.g. when the schema describes an account, and you want to be
* able to store a arbitrary number of accounts.
*
* Paths must start with and end with a forward slash character ('/')
* Paths must start with and end with a forward slash character (`/`)
* and must not contain two sequential slash characters. Paths should
* be chosen based on a domain name associated with the program or
* library to which the settings belong. Examples of paths are
* "/org/gtk/settings/file-chooser/" and "/ca/desrt/dconf-editor/".
* Paths should not start with "/apps/", "/desktop/" or "/system/" as
* `/org/gtk/settings/file-chooser/` and `/ca/desrt/dconf-editor/`.
* Paths should not start with `/apps/`, `/desktop/` or `/system/` as
* they often did in GConf.
*
* Unlike other configuration systems (like GConf), GSettings does not
* restrict keys to basic types like strings and numbers. GSettings stores
* values as #GVariant, and allows any #GVariantType for keys. Key names
* are restricted to lowercase characters, numbers and '-'. Furthermore,
* the names must begin with a lowercase character, must not end
* with a '-', and must not contain consecutive dashes.
* values as [struct@GLib.Variant], and allows any [type@GLib.VariantType] for
* keys. Key names are restricted to lowercase characters, numbers and `-`.
* Furthermore, the names must begin with a lowercase character, must not end
* with a `-`, and must not contain consecutive dashes.
*
* Similar to GConf, the default values in GSettings schemas can be
* localized, but the localized values are stored in gettext catalogs
* and looked up with the domain that is specified in the
* `gettext-domain` attribute of the <schemalist> or <schema>
* `gettext-domain` attribute of the `<schemalist>` or `<schema>`
* elements and the category that is specified in the `l10n` attribute of
* the <default> element. The string which is translated includes all text in
* the <default> element, including any surrounding quotation marks.
* the `<default>` element. The string which is translated includes all text in
* the `<default>` element, including any surrounding quotation marks.
*
* The `l10n` attribute must be set to `messages` or `time`, and sets the
* [locale category for
* translation](https://www.gnu.org/software/gettext/manual/html_node/Aspects.html#index-locale-categories-1).
* The `messages` category should be used by default; use `time` for
* translatable date or time formats. A translation comment can be added as an
* XML comment immediately above the <default> element it is recommended to
* XML comment immediately above the `<default>` element it is recommended to
* add these comments to aid translators understand the meaning and
* implications of the default value. An optional translation `context`
* attribute can be set on the <default> element to disambiguate multiple
* attribute can be set on the `<default>` element to disambiguate multiple
* defaults which use the same string.
*
* For example:
* |[
* ```xml
* <!-- Translators: A list of words which are not allowed to be typed, in
* GVariant serialization syntax.
* See: https://developer.gnome.org/glib/stable/gvariant-text.html -->
* <default l10n='messages' context='Banned words'>['bad', 'words']</default>
* ]|
* ```
*
* Translations of default values must remain syntactically valid serialized
* #GVariants (e.g. retaining any surrounding quotation marks) or runtime
* errors will occur.
* [struct@GLib.Variant]s (e.g. retaining any surrounding quotation marks) or
* runtime errors will occur.
*
* GSettings uses schemas in a compact binary form that is created
* by the [glib-compile-schemas][glib-compile-schemas]
* by the [`glib-compile-schemas`](glib-compile-schemas.html)
* utility. The input is a schema description in an XML format.
*
* A DTD for the gschema XML format can be found here:
* [gschema.dtd](https://gitlab.gnome.org/GNOME/glib/-/blob/HEAD/gio/gschema.dtd)
*
* The [glib-compile-schemas][glib-compile-schemas] tool expects schema
* The [`glib-compile-schemas`](glib-compile-schemas.html) tool expects schema
* files to have the extension `.gschema.xml`.
*
* At runtime, schemas are identified by their id (as specified in the
* id attribute of the <schema> element). The convention for schema
* ids is to use a dotted name, similar in style to a D-Bus bus name,
* e.g. "org.gnome.SessionManager". In particular, if the settings are
* At runtime, schemas are identified by their ID (as specified in the
* `id` attribute of the `<schema>` element). The convention for schema
* IDs is to use a dotted name, similar in style to a D-Bus bus name,
* e.g. `org.gnome.SessionManager`. In particular, if the settings are
* for a specific service that owns a D-Bus bus name, the D-Bus bus name
* and schema id should match. For schemas which deal with settings not
* associated with one named application, the id should not use
* StudlyCaps, e.g. "org.gnome.font-rendering".
* and schema ID should match. For schemas which deal with settings not
* associated with one named application, the ID should not use
* StudlyCaps, e.g. `org.gnome.font-rendering`.
*
* In addition to #GVariant types, keys can have types that have
* enumerated types. These can be described by a <choice>,
* <enum> or <flags> element, as seen in the
* [example][schema-enumerated]. The underlying type of such a key
* is string, but you can use g_settings_get_enum(), g_settings_set_enum(),
* g_settings_get_flags(), g_settings_set_flags() access the numeric values
* corresponding to the string value of enum and flags keys.
* In addition to [struct@GLib.Variant] types, keys can have types that have
* enumerated types. These can be described by a `<choice>`,
* `<enum>` or `<flags>` element, as seen in the
* second example below. The underlying type of such a key
* is string, but you can use [method@Gio.Settings.get_enum],
* [method@Gio.Settings.set_enum], [method@Gio.Settings.get_flags],
* [method@Gio.Settings.set_flags] access the numeric values corresponding to
* the string value of enum and flags keys.
*
* An example for default value:
* |[
* ```xml
* <schemalist>
* <schema id="org.gtk.Test" path="/org/gtk/Test/" gettext-domain="test">
*
@ -169,10 +168,10 @@
*
* </schema>
* </schemalist>
* ]|
* ```
*
* An example for ranges, choices and enumerated types:
* |[
* ```xml
* <schemalist>
*
* <enum id="org.gtk.Test.myenum">
@ -215,7 +214,7 @@
* </key>
* </schema>
* </schemalist>
* ]|
* ```
*
* ## Vendor overrides
*
@ -223,41 +222,42 @@
* an application. Sometimes, it is necessary for a vendor or distributor
* to adjust these defaults. Since patching the XML source for the schema
* is inconvenient and error-prone,
* [glib-compile-schemas][glib-compile-schemas] reads so-called vendor
* override' files. These are keyfiles in the same directory as the XML
* schema sources which can override default values. The schema id serves
* [`glib-compile-schemas`](glib-compile-schemas.html) reads so-called vendor
* override files. These are keyfiles in the same directory as the XML
* schema sources which can override default values. The schema ID serves
* as the group name in the key file, and the values are expected in
* serialized GVariant form, as in the following example:
* |[
* serialized [struct@GLib.Variant] form, as in the following example:
* ```
* [org.gtk.Example]
* key1='string'
* key2=1.5
* ]|
* ```
*
* glib-compile-schemas expects schema files to have the extension
* `glib-compile-schemas` expects schema files to have the extension
* `.gschema.override`.
*
* ## Binding
*
* A very convenient feature of GSettings lets you bind #GObject properties
* directly to settings, using g_settings_bind(). Once a GObject property
* has been bound to a setting, changes on either side are automatically
* propagated to the other side. GSettings handles details like mapping
* between GObject and GVariant types, and preventing infinite cycles.
* A very convenient feature of GSettings lets you bind [class@GObject.Object]
* properties directly to settings, using [method@Gio.Settings.bind]. Once a
* [class@GObject.Object] property has been bound to a setting, changes on
* either side are automatically propagated to the other side. GSettings handles
* details like mapping between [class@GObject.Object] and [struct@GLib.Variant]
* types, and preventing infinite cycles.
*
* This makes it very easy to hook up a preferences dialog to the
* underlying settings. To make this even more convenient, GSettings
* looks for a boolean property with the name "sensitivity" and
* looks for a boolean property with the name `sensitivity` and
* automatically binds it to the writability of the bound setting.
* If this 'magic' gets in the way, it can be suppressed with the
* %G_SETTINGS_BIND_NO_SENSITIVITY flag.
* If this magic gets in the way, it can be suppressed with the
* `G_SETTINGS_BIND_NO_SENSITIVITY` flag.
*
* ## Relocatable schemas # {#gsettings-relocatable}
* ## Relocatable schemas
*
* A relocatable schema is one with no `path` attribute specified on its
* <schema> element. By using g_settings_new_with_path(), a #GSettings object
* can be instantiated for a relocatable schema, assigning a path to the
* instance. Paths passed to g_settings_new_with_path() will typically be
* `<schema>` element. By using [ctor@Gio.Settings.new_with_path], a `GSettings`
* object can be instantiated for a relocatable schema, assigning a path to the
* instance. Paths passed to [ctor@Gio.Settings.new_with_path] will typically be
* constructed dynamically from a constant prefix plus some form of instance
* identifier; but they must still be valid GSettings paths. Paths could also
* be constant and used with a globally installed schema originating from a
@ -268,59 +268,59 @@
* `org.foo.MyApp.Window`, it could be instantiated for paths
* `/org/foo/MyApp/main/`, `/org/foo/MyApp/document-1/`,
* `/org/foo/MyApp/document-2/`, etc. If any of the paths are well-known
* they can be specified as <child> elements in the parent schema, e.g.:
* |[
* they can be specified as `<child>` elements in the parent schema, e.g.:
* ```xml
* <schema id="org.foo.MyApp" path="/org/foo/MyApp/">
* <child name="main" schema="org.foo.MyApp.Window"/>
* </schema>
* ]|
* ```
*
* ## Build system integration # {#gsettings-build-system}
* ## Build system integration
*
* GSettings comes with autotools integration to simplify compiling and
* installing schemas. To add GSettings support to an application, add the
* following to your `configure.ac`:
* |[
* ```
* GLIB_GSETTINGS
* ]|
* ```
*
* In the appropriate `Makefile.am`, use the following snippet to compile and
* install the named schema:
* |[
* ```
* gsettings_SCHEMAS = org.foo.MyApp.gschema.xml
* EXTRA_DIST = $(gsettings_SCHEMAS)
*
* @GSETTINGS_RULES@
* ]|
* ```
*
* No changes are needed to the build system to mark a schema XML file for
* translation. Assuming it sets the `gettext-domain` attribute, a schema may
* be marked for translation by adding it to `POTFILES.in`, assuming gettext
* 0.19 is in use (the preferred method for translation):
* |[
* ```
* data/org.foo.MyApp.gschema.xml
* ]|
* ```
*
* Alternatively, if intltool 0.50.1 is in use:
* |[
* ```
* [type: gettext/gsettings]data/org.foo.MyApp.gschema.xml
* ]|
* ```
*
* GSettings will use gettext to look up translations for the <summary> and
* <description> elements, and also any <default> elements which have a `l10n`
* attribute set. Translations must not be included in the `.gschema.xml` file
* by the build system, for example by using intltool XML rules with a
* GSettings will use gettext to look up translations for the `<summary>` and
* `<description>` elements, and also any `<default>` elements which have a
* `l10n` attribute set. Translations must not be included in the `.gschema.xml`
* file by the build system, for example by using intltool XML rules with a
* `.gschema.xml.in` template.
*
* If an enumerated type defined in a C header file is to be used in a GSettings
* schema, it can either be defined manually using an <enum> element in the
* schema, it can either be defined manually using an `<enum>` element in the
* schema XML, or it can be extracted automatically from the C header. This
* approach is preferred, as it ensures the two representations are always
* synchronised. To do so, add the following to the relevant `Makefile.am`:
* |[
* ```
* gsettings_ENUM_NAMESPACE = org.foo.MyApp
* gsettings_ENUM_FILES = my-app-enums.h my-app-misc.h
* ]|
* ```
*
* `gsettings_ENUM_NAMESPACE` specifies the schema namespace for the enum files,
* which are specified in `gsettings_ENUM_FILES`. This will generate a
@ -330,13 +330,6 @@
* `EXTRA_DIST`.
*/
/**
* GSettings:
*
* #GSettings is an opaque data structure and can only be accessed
* using the following functions.
**/
struct _GSettingsPrivate
{
/* where the signals go... */

View File

@ -52,17 +52,13 @@ G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE (GSettingsBackend, g_settings_backend, G_TYP
static gboolean g_settings_has_backend;
/**
* SECTION:gsettingsbackend
* @title: GSettingsBackend
* @short_description: Interface for settings backend implementations
* @include: gio/gsettingsbackend.h
* @see_also: #GSettings, #GIOExtensionPoint
* GSettingsBackend:
*
* The #GSettingsBackend interface defines a generic interface for
* The `GSettingsBackend` interface defines a generic interface for
* non-strictly-typed data that is stored in a hierarchy. To implement
* an alternative storage backend for #GSettings, you need to implement
* the #GSettingsBackend interface and then make it implement the
* extension point %G_SETTINGS_BACKEND_EXTENSION_POINT_NAME.
* an alternative storage backend for [class@Gio.Settings], you need to
* implement the `GSettingsBackend` interface and then make it implement the
* extension point `G_SETTINGS_BACKEND_EXTENSION_POINT_NAME`.
*
* The interface defines methods for reading and writing values, a
* method for determining if writing of certain values will fail
@ -72,15 +68,14 @@ static gboolean g_settings_has_backend;
* implementations must carefully adhere to the expectations of
* callers that are documented on each of the interface methods.
*
* Some of the #GSettingsBackend functions accept or return a #GTree.
* These trees always have strings as keys and #GVariant as values.
* g_settings_backend_create_tree() is a convenience function to create
* suitable trees.
* Some of the `GSettingsBackend` functions accept or return a
* [struct@GLib.Tree]. These trees always have strings as keys and
* [struct@GLib.Variant] as values.
*
* The #GSettingsBackend API is exported to allow third-party
* The `GSettingsBackend` API is exported to allow third-party
* implementations, but does not carry the same stability guarantees
* as the public GIO API. For this reason, you have to define the
* C preprocessor symbol %G_SETTINGS_ENABLE_BACKEND before including
* C preprocessor symbol `G_SETTINGS_ENABLE_BACKEND` before including
* `gio/gsettingsbackend.h`.
**/

View File

@ -53,11 +53,6 @@ G_BEGIN_DECLS
**/
#define G_SETTINGS_BACKEND_EXTENSION_POINT_NAME "gsettings-backend"
/**
* GSettingsBackend:
*
* An implementation of a settings storage repository.
**/
typedef struct _GSettingsBackendPrivate GSettingsBackendPrivate;
typedef struct _GSettingsBackendClass GSettingsBackendClass;

View File

@ -38,12 +38,9 @@
#endif
/**
* SECTION:gsettingsschema
* @short_description: Introspecting and controlling the loading
* of GSettings schemas
* @include: gio/gio.h
* GSettingsSchema:
*
* The #GSettingsSchemaSource and #GSettingsSchema APIs provide a
* The [struct@Gio.SettingsSchemaSource] and `GSettingsSchema` APIs provide a
* mechanism for advanced control over the loading of schemas and a
* mechanism for introspecting their content.
*
@ -53,20 +50,20 @@
* the schema along with itself and it won't be installed into the
* standard system directories for schemas.
*
* #GSettingsSchemaSource provides a mechanism for dealing with this by
* allowing the creation of a new 'schema source' from which schemas can
* [struct@Gio.SettingsSchemaSource] provides a mechanism for dealing with this
* by allowing the creation of a new schema source from which schemas can
* be acquired. This schema source can then become part of the metadata
* associated with the plugin and queried whenever the plugin requires
* access to some settings.
*
* Consider the following example:
*
* |[<!-- language="C" -->
* ```c
* typedef struct
* {
* ...
*
* GSettingsSchemaSource *schema_source;
* ...
*
* } Plugin;
*
* Plugin *
@ -74,18 +71,18 @@
* {
* Plugin *plugin;
*
* ...
*
*
* plugin->schema_source =
* g_settings_schema_source_new_from_directory (dir,
* g_settings_schema_source_get_default (), FALSE, NULL);
*
* ...
*
*
* return plugin;
* }
*
* ...
*
*
* GSettings *
* plugin_get_settings (Plugin *plugin,
@ -101,12 +98,12 @@
*
* if (schema == NULL)
* {
* ... disable the plugin or abort, etc ...
* disable the plugin or abort, etc
* }
*
* return g_settings_new_full (schema, NULL, NULL);
* }
* ]|
* ```
*
* The code above shows how hooks should be added to the code that
* initialises (or enables) the plugin to create the schema source and
@ -118,19 +115,19 @@
* ships a gschemas.compiled file as part of itself, and then simply do
* the following:
*
* |[<!-- language="C" -->
* ```c
* {
* GSettings *settings;
* gint some_value;
*
* settings = plugin_get_settings (self, NULL);
* some_value = g_settings_get_int (settings, "some-value");
* ...
*
* }
* ]|
* ```
*
* It's also possible that the plugin system expects the schema source
* files (ie: .gschema.xml files) instead of a gschemas.compiled file.
* files (ie: `.gschema.xml` files) instead of a `gschemas.compiled` file.
* In that case, the plugin loading system must compile the schemas for
* itself before attempting to create the settings source.
*
@ -144,13 +141,6 @@
* using the following functions.
**/
/**
* GSettingsSchema:
*
* This is an opaque structure type. You may not access it directly.
*
* Since: 2.32
**/
struct _GSettingsSchema
{
GSettingsSchemaSource *source;