Applications and libraries often contain binary or textual data that is really part of the application, rather than user data.
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 Resource 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
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 the xmllint command 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
`to-pixdata` which will use the gdk-pixbuf-pixdata command 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.
An example resource description:
<?xml version="1.0" encoding="UTF-8"?>
This will create a resource bundle with the following files:
Note that all resources in the process share the same namespace, so use Java-style path prefixes (like in the above example) to avoid
You can then use glib-compile-resources to
compile the XML to a binary bundle that you can load with 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. This will generate `get_resource()`, `register_resource()` and `unregister_resource()` functions, prefixed by the `--c-name`
argument passed to glib-compile-resources.
`get_resource()` returns the generated Resource object. The register and unregister functions register the resource
so its files can be accessed using resources_lookup_data.
Once a Resource has been created and registered all the data in it can be accessed globally in the process by using
API calls like resources_open_stream to stream the data or
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 File 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 Resource 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, Mac OS 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.