Hoogle Search
Within LTS Haskell 24.4 (ghc-9.10.2)
Note that Stackage only displays results for the latest LTS and Nightly snapshot. Learn more.
Settings :: ManagedPtr Settings -> Settingsgi-gio GI.Gio.Objects.Settings No documentation available.
type
SettingsChangeEventCallback = Maybe [Word32] -> IO Boolgi-gio GI.Gio.Objects.Settings The "change-event" signal is emitted once per change event that affects this settings object. You should connect to this signal only if you are interested in viewing groups of changes before they are split out into multiple emissions of the "changed" signal. For most use cases it is more appropriate to use the "changed" signal. In the event that the change event applies to one or more specified keys, keys will be an array of GQuark of length nKeys. In the event that the change event applies to the Settings object as a whole (ie: potentially every key has been changed) then keys will be Nothing and nKeys will be 0. The default handler for this signal invokes the "changed" signal for each affected key. If any other connected handler returns True then this default functionality will be suppressed.
type
SettingsChangedCallback = Text -> IO ()gi-gio GI.Gio.Objects.Settings The "changed" signal is emitted when a key has potentially changed. You should call one of the g_settings_get() calls to check the new value. This signal supports detailed connections. You can connect to the detailed signal "changedx" in order to only receive callbacks when key "x" changes. Note that settings only emits this signal if you have read key at least once while a signal handler was already connected for key.
type
SettingsWritableChangeEventCallback = Word32 -> IO Boolgi-gio GI.Gio.Objects.Settings The "writable-change-event" signal is emitted once per writability change event that affects this settings object. You should connect to this signal if you are interested in viewing groups of changes before they are split out into multiple emissions of the "writable-changed" signal. For most use cases it is more appropriate to use the "writable-changed" signal. In the event that the writability change applies only to a single key, key will be set to the GQuark for that key. In the event that the writability change affects the entire settings object, key will be 0. The default handler for this signal invokes the "writable-changed" and "changed" signals for each affected key. This is done because changes in writability might also imply changes in value (if for example, a new mandatory setting is introduced). If any other connected handler returns True then this default functionality will be suppressed.
type
SettingsWritableChangedCallback = Text -> IO ()gi-gio GI.Gio.Objects.Settings The "writable-changed" signal is emitted when the writability of a key has potentially changed. You should call settingsIsWritable in order to determine the new status. This signal supports detailed connections. You can connect to the detailed signal "writable-changedx" in order to only receive callbacks when the writability of "x" changes.
module GI.Gio.Objects.
SettingsBackend 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 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 (lockdown) and a change notification mechanism. The semantics of the interface are very precisely defined and 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 Tree. These trees always have strings as keys and GVariant as values. 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 gio/gsettingsbackend.h.
-
gi-gio GI.Gio.Objects.SettingsBackend Memory-managed wrapper type.
SettingsBackend :: ManagedPtr SettingsBackend -> SettingsBackendgi-gio GI.Gio.Objects.SettingsBackend No documentation available.
module GI.Gio.Structs.
SettingsSchema The SettingsSchemaSource and GSettingsSchema APIs provide a mechanism for advanced control over the loading of schemas and a mechanism for introspecting their content. Plugin loading systems that wish to provide plugins a way to access settings face the problem of how to make the schemas for these settings visible to GSettings. Typically, a plugin will want to ship the schema along with itself and it won't be installed into the standard system directories for schemas. 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 code
typedef struct { … GSettingsSchemaSource *schema_source; … } Plugin; Plugin * initialise_plugin (const gchar *dir) { 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, const gchar *schema_id) { GSettingsSchema *schema; if (schema_id == NULL) schema_id = plugin->identifier; schema = g_settings_schema_source_lookup (plugin->schema_source, schema_id, FALSE); if (schema == NULL) { … 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 how an API can be added to the plugin system to provide a convenient way for the plugin to access its settings, using the schemas that it ships. From the standpoint of the plugin, it would need to ensure that it ships a gschemas.compiled file as part of itself, and then simply do the following:c code
{ 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. In that case, the plugin loading system must compile the schemas for itself before attempting to create the settings source. Since: 2.32-
gi-gio GI.Gio.Structs.SettingsSchema Memory-managed wrapper type.