RubyGems - glib2 - Versions diffs - 1.1.8-x86-mingw32 → 1.1.9-x86-mingw32 - Mend

glib2 1.1.8-x86-mingw32 → 1.1.9-x86-mingw32

Files changed (1810) hide show

data/vendor/local/share/gtk-doc/html/gio/ch31s06.html ADDED

@@ -0,0 +1,278 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<title>Schema conversion</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.77.1">
+<link rel="home" href="index.html" title="GIO Reference Manual">
+<link rel="up" href="ch31.html" title="Migrating from GConf to GSettings">
+<link rel="prev" href="ch31s05.html" title="Change sets">
+<link rel="next" href="ch31s07.html" title="Data conversion">
+<meta name="generator" content="GTK-Doc V1.18 (XML mode)">
+<link rel="stylesheet" href="style.css" type="text/css">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="2"><tr valign="middle">
+<td><a accesskey="p" href="ch31s05.html"><img src="left.png" width="24" height="24" border="0" alt="Prev"></a></td>
+<td><a accesskey="u" href="ch31.html"><img src="up.png" width="24" height="24" border="0" alt="Up"></a></td>
+<td><a accesskey="h" href="index.html"><img src="home.png" width="24" height="24" border="0" alt="Home"></a></td>
+<th width="100%" align="center">GIO Reference Manual</th>
+<td><a accesskey="n" href="ch31s07.html"><img src="right.png" width="24" height="24" border="0" alt="Next"></a></td>
+</tr></table>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="idp12350560"></a>Schema conversion</h2></div></div></div>
+<p>
+        If you are porting your application from GConf, most likely you already
+        have a GConf schema. GConf comes with a commandline tool
+        gsettings-schema-convert that can help with the task of converting
+        a GConf schema into an equivalent GSettings schema. The tool is not
+        perfect and may need assistence in some cases.
+      </p>
+<div class="example">
+<a name="idp11155184"></a><p class="title"><b>Example 27. An example for using gsettings-schema-convert</b></p>
+<div class="example-contents">
+<p>Running <strong class="userinput"><code>gsettings-schema-convert --gconf --xml --schema-id "org.gnome.font-rendering" --output org.gnome.font-rendering.gschema.xml destop_gnome_font_rendering.schemas</code></strong> on the following <code class="filename">desktop_gnome_font_rendering.schemas</code> file:
+        </p>
+<pre class="programlisting">
+&lt;?xml version="1.0"?&gt;
+&lt;gconfschemafile&gt;
+    &lt;schemalist&gt;
+        &lt;schema&gt;
+            &lt;key&gt;/schemas/desktop/gnome/font_rendering/dpi&lt;/key&gt;
+            &lt;applyto&gt;/desktop/gnome/font_rendering/dpi&lt;/applyto&gt;
+            &lt;owner&gt;gnome&lt;/owner&gt;
+            &lt;type&gt;int&lt;/type&gt;
+            &lt;default&gt;96&lt;/default&gt;
+            &lt;locale name="C"&gt;
+                &lt;short&gt;DPI&lt;/short&gt;
+                &lt;long&gt;The resolution used for converting font sizes to pixel sizes, in dots per inch.&lt;/long&gt;
+            &lt;/locale&gt;
+        &lt;/schema&gt;
+    &lt;/schemalist&gt;
+&lt;/gconfschemafile&gt;
+</pre>
+<p>
+produces a <code class="filename">org.gnome.font-rendering.gschema.xml</code> file with the following content:
+</p>
+<pre class="programlisting">
+&lt;schemalist&gt;
+  &lt;schema id="org.gnome.font-rendering" path="/desktop/gnome/font_rendering/"&gt;
+    &lt;key name="dpi" type="i"&gt;
+      &lt;default&gt;96&lt;/default&gt;
+      &lt;summary&gt;DPI&lt;/summary&gt;
+      &lt;description&gt;The resolution used for converting font sizes to pixel sizes, in dots per inch.&lt;/description&gt;
+    &lt;/key&gt;
+  &lt;/schema&gt;
+&lt;/schemalist&gt;
+</pre>
+<p>
+</p>
+</div>
+</div>
+<br class="example-break"><p>
+       GSettings schemas are identified at runtime by their id (as specified
+       in the XML source file). It is recommended to use a dotted name as schema
+       id, similar in style to a D-Bus bus name, e.g. "org.gnome.SessionManager".
+       In cases where the settings are general and not specific to one application,
+       the id should not use StudlyCaps, e.g. "org.gnome.font-rendering".
+       The filename used for the XML schema source is immaterial, but
+       schema compiler expects the files to have the extension
+       <code class="filename">.gschema.xml</code>. It is recommended to simply
+       use the schema id as the filename, followed by this extension,
+       e.g. <code class="filename">org.gnome.SessionManager.gschema.xml</code>.
+      </p>
+<p>
+        The XML source file for your GSettings schema needs to get installed
+        into <code class="filename">$datadir/glib-2.0/schemas</code>, and needs to be
+        compiled into a binary form. At runtime, GSettings looks for compiled
+        schemas in the <code class="filename">glib-2.0/schemas</code> subdirectories
+        of all <code class="envar">XDG_DATA_DIRS</code> directories, so if you install
+        your schema in a different location, you need to set the
+        <code class="envar">XDG_DATA_DIRS</code> environment variable appropriately.
+      </p>
+<p>
+        Schemas are compiled into binary form by the
+        <a href="glib-compile-schemas.html">glib-compile-schemas</a> utility.
+        GIO provides a <code class="literal">glib_compile_schemas</code>
+        variable for the schema compiler.
+      </p>
+<p>
+        You can ignore all of this by using the provided m4 macros.  To
+        do this, add to your <code class="filename">configure.ac</code>:
+</p>
+<pre class="programlisting">
+GLIB_GSETTINGS
+</pre>
+<p>
+        The corresponding <code class="filename">Makefile.am</code> fragment looks like
+        this:
+</p>
+<pre class="programlisting">
+# gsettings_SCHEMAS is a list of all the schemas you want to install
+gsettings_SCHEMAS = my.app.gschema.xml
+# include the appropriate makefile rules for schema handling
+@GSETTINGS_RULES@
+</pre>
+<p>
+      </p>
+<p>
+        This is not sufficient on its own.  You need to mention what the source
+        of the <code class="filename">my.app.gschema.xml</code> file is.  If the schema
+        file is distributed directly with your project's tarball then a mention
+        in <code class="varname">EXTRA_DIST</code> is appropriate.  If the schema file is
+        generated from another source then you will need the appropriate rule
+        for that, plus probably an item in <code class="varname">EXTRA_DIST</code> for the
+        source files used by that rule.
+      </p>
+<p>
+        One possible pitfall in doing schema conversion is that the default
+        values in GSettings schemas are parsed by the <a href="./../glib/glib/glib-GVariant.html#GVariant"><span class="type">GVariant</span></a> parser.
+        This means that strings need to include quotes in the XML.  Also note
+        that the types are now specified as <a href="./../glib/glib/glib-GVariant.html#GVariant"><span class="type">GVariant</span></a> type strings.
+        </p>
+<pre class="programlisting">
+&lt;type&gt;string&lt;/type&gt;
+&lt;default&gt;rgb&lt;/default&gt;
+        </pre>
+<p>
+        becomes
+        </p>
+<pre class="programlisting">
+&lt;key name="rgba-order" type="s"&gt;
+  &lt;default&gt;'rgb'&lt;/default&gt; &lt;!-- note quotes --&gt;
+&lt;/key&gt;
+        </pre>
+<p>
+      </p>
+<p>
+        Another possible complication is that GConf specifies full paths
+        for each key, while a GSettings schema has a 'path' attribute that
+        contains the prefix for all the keys in the schema, and individual
+        keys just have a simple name. So
+        </p>
+<pre class="programlisting">
+&lt;key&gt;/schemas/desktop/gnome/font_rendering/antialiasing&lt;/key&gt;
+        </pre>
+<p>
+        becomes
+        </p>
+<pre class="programlisting">
+&lt;schema id="org.gnome.font" path="/desktop/gnome/font_rendering/"&gt;
+  &lt;key name="antialiasing" type="s"&gt;
+        </pre>
+<p>
+      </p>
+<p>
+        Default values can be localized in both GConf and GSettings schemas,
+        but GSettings uses gettext for the localization. You can specify
+        the gettext domain to use in the <code class="sgmltag-attribute">gettext-domain</code>
+        attribute. Therefore, when converting localized defaults in GConf,
+        </p>
+<pre class="programlisting">
+&lt;key&gt;/schemas/apps/my_app/font_size&lt;/key&gt;
+  &lt;locale name="C"&gt;
+    &lt;default&gt;18&lt;/default&gt;
+  &lt;/locale&gt;
+  &lt;locale name="be"&gt;
+    &lt;default&gt;24&lt;/default&gt;
+  &lt;/locale&gt;
+&lt;/key&gt;
+        </pre>
+<p>
+        becomes
+        </p>
+<pre class="programlisting">
+&lt;schema id="..." gettext-domain="your-domain"&gt;
+ ...
+&lt;key name="font-size" type="i"&gt;
+  &lt;default l10n="messages" context="font_size"&gt;18&lt;/default&gt;
+&lt;/key&gt;
+        </pre>
+<p>
+      </p>
+<p>
+        GSettings uses gettext for translation of default values.
+        The string that is translated is exactly the string that appears
+        inside of the <code class="sgmltag-starttag">&lt;default&gt;</code> element.  This
+        includes the quotation marks that appear around strings.
+        Default values must be marked with the <code class="varname">l10n</code>
+        attribute in the <code class="sgmltag-starttag">&lt;default&gt;</code> tag, which
+        should be set as equal to <code class="literal">'messages'</code> or
+        <code class="literal">'time'</code> depending on the desired category.  An
+        optional translation context can also be specified with the
+        <code class="varname">context</code> attribute, as in the example.  This
+        is usually recommended, since the string "<code class="literal">18</code>"
+        is not particularly easy to translate without context.  The
+        translated version of the default value should be stored in the
+        specified <code class="varname">gettext-domain</code>.  Care must be taken
+        during translation to ensure that all translated values remain
+        syntactically valid; mistakes here will cause runtime errors.
+      </p>
+<p>
+        GSettings schemas have optional <code class="sgmltag-starttag">&lt;summary&gt;</code> and
+        <code class="sgmltag-starttag">&lt;description&gt;</code> elements for each key which
+        correspond to the <code class="sgmltag-starttag">&lt;short&gt;</code> and
+        <code class="sgmltag-starttag">&lt;long&gt;</code> elements in the GConf schema and
+        will be used in similar ways by a future gsettings-editor, so you
+        should use the same conventions for them: The summary is just a short
+        label with no punctuation, the description can be one or more complete
+        sentences. If multiple paragraphs are desired for the description, the
+        paragraphs should be separated by a completely empty line.
+      </p>
+<p>
+        Translations for these strings will also be handled
+        via gettext, so you should arrange for these strings to be
+        extracted into your gettext catalog. One way to do that is to use
+        intltool. Since intltool 0.50.1, schema files are
+        supported, so all you have to do is to add your .gschema.xml
+        files to <code class="filename">POTFILES.in</code> with a line like
+        </p>
+<pre class="programlisting">
+        [type: gettext/gsettings]data/org.foo.MyApp.gschema.xml
+        </pre>
+<p>
+      </p>
+<p>
+        GSettings is a bit more restrictive about key names than GConf. Key
+        names in GSettings can be at most 32 characters long, and must only
+        consist of lowercase characters, numbers and dashes, with no
+        consecutive dashes. The first character must not be a number or dash,
+        and the last character cannot be '-'.
+      </p>
+<p>
+        If you are using the GConf backend for GSettings during the
+        transition, you may want to keep your key names the same they
+        were in GConf, so that existing settings in the users GConf
+        database are preserved. You can achieve this by using the
+        <code class="option">--allow-any-name</code> with the
+        <a href="glib-compile-schemas.html">glib-compile-schemas</a> schema
+        compiler. Note that this option is only meant
+        to ease the process of porting your application, allowing parts
+        of your application to continue to access GConf and parts to use
+        GSettings. By the time you have finished porting your application
+        you must ensure that all key names are valid.
+      </p>
+</div>
+<div class="footer">
+<hr>
+          Generated by GTK-Doc V1.18</div>
+</body>
+</html>

data/vendor/local/share/gtk-doc/html/gio/ch31s07.html ADDED

@@ -0,0 +1,160 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<title>Data conversion</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.77.1">
+<link rel="home" href="index.html" title="GIO Reference Manual">
+<link rel="up" href="ch31.html" title="Migrating from GConf to GSettings">
+<link rel="prev" href="ch31s06.html" title="Schema conversion">
+<link rel="next" href="ch32.html" title="Migrating to GDBus">
+<meta name="generator" content="GTK-Doc V1.18 (XML mode)">
+<link rel="stylesheet" href="style.css" type="text/css">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="2"><tr valign="middle">
+<td><a accesskey="p" href="ch31s06.html"><img src="left.png" width="24" height="24" border="0" alt="Prev"></a></td>
+<td><a accesskey="u" href="ch31.html"><img src="up.png" width="24" height="24" border="0" alt="Up"></a></td>
+<td><a accesskey="h" href="index.html"><img src="home.png" width="24" height="24" border="0" alt="Home"></a></td>
+<th width="100%" align="center">GIO Reference Manual</th>
+<td><a accesskey="n" href="ch32.html"><img src="right.png" width="24" height="24" border="0" alt="Next"></a></td>
+</tr></table>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="idp40389376"></a>Data conversion</h2></div></div></div>
+<p>
+        GConf comes with a GSettings backend that can be used to
+        facility the transition to the GSettings API until you are
+        ready to make the jump to a different backend (most likely
+        dconf). To use it, you need to set the <code class="envar">GSETTINGS_BACKEND</code>
+        to 'gconf', e.g. by using
+</p>
+<pre class="programlisting">
+  g_setenv ("GSETTINGS_BACKEND", "gconf", TRUE);
+</pre>
+<p>
+        early on in your program. Note that this backend is meant purely
+        as a transition tool, and should not be used in production.
+      </p>
+<p>
+        GConf also comes with a utility called
+        <span class="command"><strong>gsettings-data-convert</strong></span>, which is designed to help
+        with the task of migrating user settings from GConf into another
+        GSettings backend. It can be run manually, but it is designed to be
+        executed automatically, every time a user logs in. It keeps track of
+        the data migrations that it has already done, and it is harmless to
+        run it more than once.
+      </p>
+<p>
+        To make use of this utility, you must install a keyfile in the
+        directory <code class="filename">/usr/share/GConf/gsettings</code> which
+        lists the GSettings keys and GConf paths to map to each other, for
+        each schema that you want to migrate user data for.
+      </p>
+<p>
+        Here is an example:
+        </p>
+<pre class="programlisting">
+[org.gnome.fonts]
+antialiasing = /desktop/gnome/font_rendering/antialiasing
+dpi = /desktop/gnome/font_rendering/dpi
+hinting = /desktop/gnome/font_rendering/hinting
+rgba-order = /desktop/gnome/font_rendering/rgba_order
+[apps.myapp:/path/to/myapps/]
+some-odd-key1 = /apps/myapp/some_ODD-key1
+        </pre>
+<p>
+        The last key demonstrates that it may be necessary to modify the key
+        name to comply with stricter GSettings key name rules. Of course,
+        that means your application must use the new key names when looking
+        up settings in GSettings.
+      </p>
+<p>
+        The last group in the example also shows how to handle the case
+        of 'relocatable' schemas, which don't have a fixed path. You can
+        specify the path to use in the group name, separated by a colon.
+      </p>
+<p>
+        There are some limitations: <span class="command"><strong>gsettings-data-convert</strong></span>
+        does not do any transformation of the values. And it does not handle
+        complex GConf types other than lists of strings or integers.
+      </p>
+<p>
+        Don't forget to require GConf 2.31.1 or newer in your configure
+        script if you are making use of the GConf backend or the conversion
+        utility.
+      </p>
+<p>
+        If, as an application developer, you are interested in manually
+        ensuring that <span class="command"><strong>gsettings-data-convert</strong></span> has been
+        invoked (for example, to deal with the case where the user is
+        logged in during a distribution upgrade or for non-XDG desktop
+        environments which do not run the command as an autostart) you
+        may invoke it manually during your program initialisation.  This
+        is not recommended for all application authors -- it is your
+        choice if this use case concerns you enough.
+      </p>
+<p>
+        Internally, <span class="command"><strong>gsettings-data-convert</strong></span> uses a
+        keyfile to track which settings have been migrated.  The
+        following code fragment will check that keyfile to see if your
+        data conversion script has been run yet and, if not, will
+        attempt to invoke the tool to run it.  You should adapt it to
+        your application as you see fit.
+      </p>
+<p>
+        </p>
+<pre class="programlisting">
+static void
+ensure_migrated (const gchar *name)
+{
+  gboolean needed = TRUE;
+  GKeyFile *kf;
+  gchar **list;
+  gsize i, n;
+  kf = g_key_file_new ();
+  g_key_file_load_from_data_dirs (kf, "gsettings-data-convert",
+                                  NULL, G_KEY_FILE_NONE, NULL);
+  list = g_key_file_get_string_list (kf, "State", "converted", &amp;n, NULL);
+  if (list)
+    {
+      for (i = 0; i &lt; n; i++)
+        if (strcmp (list[i], name) == 0)
+          {
+            needed = FALSE;
+            break;
+          }
+      g_strfreev (list);
+    }
+  g_key_file_free (kf);
+  if (needed)
+    g_spawn_command_line_sync ("gsettings-data-convert",
+                               NULL, NULL, NULL, NULL);
+}
+        </pre>
+<p>
+      </p>
+<p>
+        Although there is the possibility that the
+        <span class="command"><strong>gsettings-data-convert</strong></span> script will end up
+        running multiple times concurrently with this approach, it is
+        believed that this is safe.
+      </p>
+</div>
+<div class="footer">
+<hr>
+          Generated by GTK-Doc V1.18</div>
+</body>
+</html>

data/vendor/local/share/gtk-doc/html/gio/ch32.html ADDED

@@ -0,0 +1,113 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<title>Migrating to GDBus</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.77.1">
+<link rel="home" href="index.html" title="GIO Reference Manual">
+<link rel="up" href="migrating.html" title="Part III. Migrating to GIO">
+<link rel="prev" href="ch31s07.html" title="Data conversion">
+<link rel="next" href="ch32s02.html" title="API comparison">
+<meta name="generator" content="GTK-Doc V1.18 (XML mode)">
+<link rel="stylesheet" href="style.css" type="text/css">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="2"><tr valign="middle">
+<td><a accesskey="p" href="ch31s07.html"><img src="left.png" width="24" height="24" border="0" alt="Prev"></a></td>
+<td><a accesskey="u" href="migrating.html"><img src="up.png" width="24" height="24" border="0" alt="Up"></a></td>
+<td><a accesskey="h" href="index.html"><img src="home.png" width="24" height="24" border="0" alt="Home"></a></td>
+<th width="100%" align="center">GIO Reference Manual</th>
+<td><a accesskey="n" href="ch32s02.html"><img src="right.png" width="24" height="24" border="0" alt="Next"></a></td>
+</tr></table>
+<div class="chapter">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="idp68843408"></a>Migrating to GDBus</h2></div></div></div>
+<div class="toc"><dl>
+<dt><span class="section"><a href="ch32.html#idp79199584">Conceptual differences</a></span></dt>
+<dt><span class="section"><a href="ch32s02.html">API comparison</a></span></dt>
+<dt><span class="section"><a href="ch32s03.html">Owning bus names</a></span></dt>
+<dt><span class="section"><a href="ch32s04.html">Creating proxies for well-known names</a></span></dt>
+<dt><span class="section"><a href="ch32s05.html">Generating code and docs</a></span></dt>
+<dd><dl>
+<dt><span class="section"><a href="ch32s05.html#gdbus-example-gdbus-codegen">Using gdbus-codegen</a></span></dt>
+<dt>
+<span class="refentrytitle"><a href="gdbus-org.gtk.GDBus.Example.ObjectManager.Animal.html">org.gtk.GDBus.Example.ObjectManager.Animal</a></span><span class="refpurpose"> — Example docs generated by gdbus-codegen</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="gdbus-org.gtk.GDBus.Example.ObjectManager.Cat.html">org.gtk.GDBus.Example.ObjectManager.Cat</a></span><span class="refpurpose"> — More example docs generated by gdbus-codegen</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="ExampleAnimal.html">ExampleAnimal</a></span><span class="refpurpose"> — Generated C code for the org.gtk.GDBus.Example.ObjectManager.Animal D-Bus interface</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="ExampleCat.html">ExampleCat</a></span><span class="refpurpose"> — Generated C code for the org.gtk.GDBus.Example.ObjectManager.Cat D-Bus interface</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="ExampleObject.html">ExampleObject</a></span><span class="refpurpose"> — Specialized GDBusObject types</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="ExampleObjectManagerClient.html">ExampleObjectManagerClient</a></span><span class="refpurpose"> — Generated GDBusObjectManagerClient type</span>
+</dt>
+</dl></dd>
+</dl></div>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="idp79199584"></a>Conceptual differences</h2></div></div></div>
+<p>
+      The central concepts of D-Bus are modelled in a very similar way
+      in dbus-glib and GDBus. Both have a objects representing connections,
+      proxies and method invocations. But there are some important
+      differences:
+      </p>
+<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
+<li class="listitem"><p>
+          dbus-glib uses the <a class="ulink" href="http://www.freedesktop.org/wiki/Software/dbus#ReferenceImplementation.28dbus-daemonandlibdbus.29" target="_top">libdbus
+          reference implementation</a>, GDBus doesn't. Instead, it
+          relies on GIO streams as transport layer, and has its own
+          implementation for the the D-Bus connection setup and
+          authentication. Apart from using streams as transport,
+          avoiding libdbus also lets GDBus avoid some thorny
+          multithreading issues.
+        </p></li>
+<li class="listitem"><p>
+          dbus-glib uses the GObject type system for method arguments and
+          return values, including a homegrown container specialization
+          mechanism. GDBus relies on the <a href="./../glib/glib/glib-GVariant.html#GVariant"><span class="type">GVariant</span></a> type system which is
+          explicitly designed to match D-Bus types.
+        </p></li>
+<li class="listitem"><p>
+          dbus-glib models only D-Bus interfaces and does not provide
+          any types for objects. GDBus models both D-Bus interfaces
+          (via the <a class="link" href="GDBusInterface.html" title="GDBusInterface"><span class="type">GDBusInterface</span></a>, <a class="link" href="GDBusProxy.html" title="GDBusProxy"><span class="type">GDBusProxy</span></a> and
+          <a class="link" href="GDBusInterfaceSkeleton.html" title="GDBusInterfaceSkeleton"><span class="type">GDBusInterfaceSkeleton</span></a> types) and objects (via the
+          <a class="link" href="GDBusObject.html" title="GDBusObject"><span class="type">GDBusObject</span></a>, <a class="link" href="GDBusObjectSkeleton.html" title="GDBusObjectSkeleton"><span class="type">GDBusObjectSkeleton</span></a> and <a class="link" href="GDBusObjectProxy.html" title="GDBusObjectProxy"><span class="type">GDBusObjectProxy</span></a> types).
+        </p></li>
+<li class="listitem"><p>
+          GDBus includes native support for the <a class="ulink" href="http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-properties" target="_top">org.freedesktop.DBus.Properties</a> (via the <a class="link" href="GDBusProxy.html" title="GDBusProxy"><span class="type">GDBusProxy</span></a> type) and <a class="ulink" href="http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-objectmanager" target="_top">org.freedesktop.DBus.ObjectManager</a> D-Bus interfaces, dbus-glib doesn't.
+        </p></li>
+<li class="listitem"><p>
+          The typical way to export an object in dbus-glib involves
+          generating glue code from XML introspection data using
+          <span class="command"><strong>dbus-binding-tool</strong></span>. GDBus provides a
+          similar tool called <span class="command"><strong><a href="gdbus-codegen.html">gdbus-codegen</a></strong></span> that
+          can also generate Docbook D-Bus interface documentation.
+        </p></li>
+<li class="listitem"><p>
+          dbus-glib doesn't provide any convenience API for owning and
+          watching bus names, GDBus provides the <a class="link" href="gio-Owning-Bus-Names.html#g-bus-own-name" title="g_bus_own_name ()"><code class="function">g_bus_own_name()</code></a> and
+          <a class="link" href="gio-Watching-Bus-Names.html#g-bus-watch-name" title="g_bus_watch_name ()"><code class="function">g_bus_watch_name()</code></a> family of convenience functions.
+        </p></li>
+<li class="listitem"><p>
+          GDBus provides API to parse, generate and work with <a class="link" href="gio-D-Bus-Introspection-Data.html" title="D-Bus Introspection Data">Introspection
+          XML</a>, dbus-glib doesn't.
+        </p></li>
+</ul></div>
+<p>
+    </p>
+</div>
+</div>
+<div class="footer">
+<hr>
+          Generated by GTK-Doc V1.18</div>
+</body>
+</html>