From c16c639729ff5da0467c934c1a474feb0aec999b Mon Sep 17 00:00:00 2001 From: Philip Withnall Date: Thu, 2 Nov 2023 16:22:47 +0000 Subject: [PATCH] docs: Move the GSettings SECTIONs Move them to the struct docs. Signed-off-by: Philip Withnall Helps: #3037 --- gio/gsettings.c | 193 ++++++++++++++++++++--------------------- gio/gsettingsbackend.c | 25 +++--- gio/gsettingsbackend.h | 5 -- gio/gsettingsschema.c | 42 ++++----- 4 files changed, 119 insertions(+), 146 deletions(-) diff --git a/gio/gsettings.c b/gio/gsettings.c index a2c3dd0e4..bd36d7829 100644 --- a/gio/gsettings.c +++ b/gio/gsettings.c @@ -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 doesn’t * 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 or + * `gettext-domain` attribute of the `` or `` * elements and the category that is specified in the `l10n` attribute of - * the element. The string which is translated includes all text in - * the element, including any surrounding quotation marks. + * the `` element. The string which is translated includes all text in + * the `` 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 element — it is recommended to + * XML comment immediately above the `` 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 element to disambiguate multiple + * attribute can be set on the `` element to disambiguate multiple * defaults which use the same string. * * For example: - * |[ + * ```xml * * ['bad', 'words'] - * ]| + * ``` * * 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 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 `` 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 , - * or 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 ``, + * `` or `` 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 * * * @@ -169,10 +168,10 @@ * * * - * ]| + * ``` * * An example for ranges, choices and enumerated types: - * |[ + * ```xml * * * @@ -215,7 +214,7 @@ * * * - * ]| + * ``` * * ## 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: - * |[ - * [org.gtk.Example] - * key1='string' - * key2=1.5 - * ]| + * 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 - * 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 + * `` 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 elements in the parent schema, e.g.: - * |[ + * they can be specified as `` elements in the parent schema, e.g.: + * ```xml * * * - * ]| + * ``` * - * ## 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 and - * elements, and also any 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 `` and + * `` elements, and also any `` 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 element in the + * schema, it can either be defined manually using an `` 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... */ diff --git a/gio/gsettingsbackend.c b/gio/gsettingsbackend.c index bc9400875..d11d1fd97 100644 --- a/gio/gsettingsbackend.c +++ b/gio/gsettingsbackend.c @@ -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`. **/ diff --git a/gio/gsettingsbackend.h b/gio/gsettingsbackend.h index f579bf66f..2649605dd 100644 --- a/gio/gsettingsbackend.h +++ b/gio/gsettingsbackend.h @@ -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; diff --git a/gio/gsettingsschema.c b/gio/gsettingsschema.c index 2a2da65fd..b1918657d 100644 --- a/gio/gsettingsschema.c +++ b/gio/gsettingsschema.c @@ -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: * - * |[ + * ```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: * - * |[ + * ```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;