Sets our main struct and passes it to the parent class
Returns all the names of children at the specified path in the resource. The return result is a NULL terminated list of strings which should be released with g_strfreev(). lookup_flags controls the behaviour of the lookup. Since 2.32
Looks for a file at the specified path in the resource and if found returns information about it. lookup_flags controls the behaviour of the lookup. Since 2.32
Looks for a file at the specified path in the resource and returns a GBytes that lets you directly access the data in memory. The data is always followed by a zero byte, so you can safely use the data as a C string. However, that byte is not included in the size of the GBytes. For uncompressed resource files this is a pointer directly into the resource bundle, which is typically in some readonly data section in the program binary. For compressed files we allocate memory on the heap and automatically uncompress the data. lookup_flags controls the behaviour of the lookup. Since 2.32
Looks for a file at the specified path in the resource and returns a GInputStream that lets you read the data. lookup_flags controls the behaviour of the lookup. Since 2.32
Atomically increments the reference count of array by one. This function is MT-safe and may be called from any thread. Since 2.32
Atomically decrements the reference count of resource by one. If the reference count drops to 0, all memory allocated by the array is released. This function is MT-safe and may be called from any thread. Since 2.32
Registers the resource with the process-global set of resources. Once a resource is registered the files in it can be accessed with the global resource lookup functions like g_resources_lookup_data(). Since 2.32
Unregisters the resource from the process-global set of resources. Since 2.32
the main Gtk struct as a void*
Loads a binary resource bundle and creates a GResource representation of it, allowing you to query it for data. If you want to use this resource in the global resource namespace you need to register it with g_resources_register(). Since 2.32
Creates a GResource from a reference to the binary resource bundle. This will keep a reference to data while the resource lives, so the data should not be modified or freed. If you want to use this resource in the global resource namespace you need to register it with g_resources_register(). Since 2.32
Returns all the names of children at the specified path in the set of globally registered resources. The return result is a NULL terminated list of strings which should be released with g_strfreev(). lookup_flags controls the behaviour of the lookup. Since 2.32
Looks for a file at the specified path in the set of globally registered resources and if found returns information about it. lookup_flags controls the behaviour of the lookup. Since 2.32
Looks for a file at the specified path in the set of globally registered resources and returns a GBytes that lets you directly access the data in memory. The data is always followed by a zero byte, so you can safely use the data as a C string. However, that byte is not included in the size of the GBytes. For uncompressed resource files this is a pointer directly into the resource bundle, which is typically in some readonly data section in the program binary. For compressed files we allocate memory on the heap and automatically uncompress the data. lookup_flags controls the behaviour of the lookup. Since 2.32
Looks for a file at the specified path in the set of globally registered resources and returns a GInputStream that lets you read the data. lookup_flags controls the behaviour of the lookup. Since 2.32
Finalized a GResource initialized by g_static_resource_init(). This is normally used by code generated by glib-compile-resources and is not typically used by other code. Since 2.32
Gets the GResource that was registered by a call to g_static_resource_init(). This is normally used by code generated by glib-compile-resources and is not typically used by other code. Since 2.32
Initializes a GResource from static data using a GStaticResource. This is normally used by code generated by glib-compile-resources and is not typically used by other code. Since 2.32
the main Gtk struct
Applications and libraries often contain binary or textual data that is really part of the application, rather than user data. For instance GtkBuilder .ui files, splashscreen images, GMenu markup xml, CSS files, icons, etc. These are often shipped as files in $datadir/appname, or manually included as literal strings in the code.
The GResource API and the glib-compile-resources program provide a convenient and efficient alternative to this which has some nice properties. You maintain the files as normal files, so its easy to edit them, but during the build the files are combined into a binary bundle that is linked into the executable. This means that loading the resource files are efficient (as they are already in memory, shared with other instances) and simple (no need to check for things like I/O errors or locate the files in the filesystem). It also makes it easier to create relocatable applications.
Resource files can also be marked as compressed. Such files will be included in the resource bundle in a compressed form, but will be automatically uncompressed when the resource is used. This is very useful e.g. for larger text files that are parsed once (or rarely) and then thrown away.
Resource files can also be marked to be preprocessed, by setting the value of the preprocess attribute to a comma-separated list of preprocessing options. The only options currently supported are:
xml-stripblanks which will use xmllint to strip ignorable whitespace from the xml file. For this to work, the XMLLINT environment variable must be set to the full path to the xmllint executable, or xmllint must be in the PATH; otherwise the preprocessing step is skipped.
to-pixdata which will use gdk-pixbuf-pixdata to convert images to the GdkPixdata format, which allows you to create pixbufs directly using the data inside the resource file, rather than an (uncompressed) copy if it. For this, the gdk-pixbuf-pixdata program must be in the PATH, or the GDK_PIXBUF_PIXDATA environment variable must be set to the full path to the gdk-pixbuf-pixdata executable; otherwise the resource compiler will abort.
Resource bundles are created by the glib-compile-resources program which takes an xml file that describes the bundle, and a set of files that the xml references. These are combined into a binary resource bundle.
This will create a resource bundle with the following files:
/org/gtk/Example/data/splashscreen.png /org/gtk/Example/dialog.ui /org/gtk/Example/menumarkup.xml
Note that all resources in the process share the same namespace, so use java-style path prefixes (like in the above example) to avoid conflicts.
You can then use glib-compile-resources to compile the xml to a binary bundle that you can load with g_resource_load(). However, its more common to use the --generate-source and --generate-header arguments to create a source file and header to link directly into your application.
Once a GResource has been created and registered all the data in it can be accessed globally in the process by using API calls like g_resources_open_stream() to stream the data or g_resources_lookup_data() to get a direct pointer to the data. You can also use uris like "resource:///org/gtk/Example/data/splashscreen.png" with GFile to access the resource data.
There are two forms of the generated source, the default version uses the compiler support for constructor and destructor functions (where available) to automatically create and register the GResource on startup or library load time. If you pass --manual-register two functions to register/unregister the resource is instead created. This requires an explicit initialization call in your application/library, but it works on all platforms, even on the minor ones where this is not available. (Constructor support is available for at least Win32, MacOS and Linux.)
Note that resource data can point directly into the data segment of e.g. a library, so if you are unloading libraries during runtime you need to be very careful with keeping around pointers to data from a resource, as this goes away when the library is unloaded. However, in practice this is not generally a problem, since most resource accesses is for your own resources, and resource data is often used once, during parsing, and then released.