Delete the given preset.
Gets the @value for an existing meta data @tag. Meta data @tag names can be something like e.g. "comment". Returned values need to be released when done.
Get a copy of preset names as a %NULL terminated string array.
Get the main Gtk struct
Get a the names of the GObject properties that can be used for presets.
the main Gtk struct as a void*
Check if one can add new presets, change existing ones and remove presets.
Load the given preset.
Renames a preset. If there is already a preset by the @new_name it will be overwritten.
Save the current object settings as a preset under the given name. If there is already a preset by this @name it will be overwritten.
Sets a new @value for an existing meta data item or adds a new item. Meta data @tag names can be something like e.g. "comment". Supplying %NULL for the @value will unset an existing value.
Gets the directory for application specific presets if set by the application.
Sets an extra directory as an absolute path that should be considered when looking for presets. Any presets in the application dir will shadow the system presets.
This interface offers methods to query and manipulate parameter preset sets. A preset is a bunch of property settings, together with meta data and a name. The name of a preset serves as key for subsequent method calls to manipulate single presets. All instances of one type will share the list of presets. The list is created on demand, if presets are not used, the list is not created.
The interface comes with a default implementation that serves most plugins. Wrapper plugins will override most methods to implement support for the native preset format of those wrapped plugins. One method that is useful to be overridden is gst_preset_get_property_names(). With that one can control which properties are saved and in which order. When implementing support for read-only presets, one should set the vmethods for gst_preset_save_preset() and gst_preset_delete_preset() to %NULL. Applications can use gst_preset_is_editable() to check for that.
The default implementation supports presets located in a system directory, application specific directory and in the users home directory. When getting a list of presets individual presets are read and overlaid in 1) system, 2) application and 3) user order. Whenever an earlier entry is newer, the later entries will be updated. Since 1.8 you can also provide extra paths where to find presets through the GST_PRESET_PATH environment variable. Presets found in those paths will be concidered as "app presets".