[glib] gresource: Minor capitalisation fixes in documentation
- From: Philip Withnall <pwithnall src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [glib] gresource: Minor capitalisation fixes in documentation
- Date: Thu, 14 May 2015 07:32:10 +0000 (UTC)
commit a8c157f92be6915549e1ec06e611e72da935385b
Author: Philip Withnall <philip withnall collabora co uk>
Date: Thu May 14 08:15:46 2015 +0100
gresource: Minor capitalisation fixes in documentation
gio/gresource.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
---
diff --git a/gio/gresource.c b/gio/gresource.c
index a611929..a51e60a 100644
--- a/gio/gresource.c
+++ b/gio/gresource.c
@@ -47,7 +47,7 @@ G_DEFINE_BOXED_TYPE (GResource, g_resource, g_resource_ref, g_resource_unref)
*
* 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,
+ * #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.
*
@@ -68,7 +68,7 @@ G_DEFINE_BOXED_TYPE (GResource, g_resource, g_resource_ref, g_resource_unref)
* 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,
+ * 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.
@@ -81,7 +81,7 @@ G_DEFINE_BOXED_TYPE (GResource, g_resource, g_resource_ref, g_resource_unref)
* abort.
*
* Resource bundles are created by the [glib-compile-resources][glib-compile-resources] program
- * which takes an xml file that describes the bundle, and a set of files that the xml references. These
+ * 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:
@@ -103,23 +103,23 @@ G_DEFINE_BOXED_TYPE (GResource, g_resource, g_resource_ref, g_resource_unref)
* /org/gtk/Example/menumarkup.xml
* ]|
*
- * Note that all resources in the process share the same namespace, so use java-style
+ * 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][glib-compile-resources] to compile the xml to a
+ * You can then use [glib-compile-resources][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
+ * 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.)
+ * 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]