Documentation/Maemo 5 Developer Guide/DBus/Using GLib Wrappers For D-Bus

=Using GLib wrappers for D-Bus =

Introduction to GObjects
In order to support runtime binding of GTK+ widgets to interpreted languages, a somewhat complicated system for implementing object-oriented machinery for C was developed. Depending on the particular viewpoint, this system is either called GObject or GType. GType is the low-level runtime type system, which is used to implement GObjects, and GObjects are the implementations of objects using the GType framework. For a short introduction about GObjects, please see the Wikipedia entry on GType. GObject/GType is part of GLib, but one might note that most of GLib is useable without the GType part of the library. In fact, the GObject/GType functionality is separated into its own library (libgobject).

The following example will use the GType in order to implement a very simple object that will be published over the D-Bus. This also means that some of the inherent complexity involved in implementing a fully fledged GObject can be forgone. For this reason, while the object will be usable over the D-Bus, it might not have all the support required to use it directly as a GObject (full dynamic type registration and properties are missing).

The implementation will be a simple non-inheriting stand-alone class, implementing an interface to access and modify two private members: value1 and value2, first of which is an 32-bit signed integer, and the second a gdouble.

It will be necessary to implement the per-class constructor as well as the per-object constructor. Both of these will be quite short for the first version of the implementation.

D-Bus Interface Definition Using XML
Since the primary objective here is to make the object available over D-Bus, the example will start by covering one of the easiest way of achieving this: the dbus-bindings-tool. The tool will generate a lot of the bindings code for both the client and server side. As its input, it uses an XML file describing the interface for the service that is being implemented.

The first step is to describe one method in XML. Each method is described with a separate method element, whose name attribute is the name of the method to be generated (this name will be copied into the generated stub code automatically by the tool). The first method is setvalue1, which will get one argument, new_value, which is an 32-bit signed integer: glib-dbus-sync/value-dbus-interface.xml

  &lt;!- setvalue1(int newValue): sets value1 -&gt;   &lt;method  name   =  "setvalue1"   &gt;   &lt;arg  type   =  "i"  name   =  "new_value"  direction   =  <font color="#FF0000">"in"   <font color="#0000FF">/&gt;   <font color="#0000FF">&lt;/method&gt;  </tt>

Each argument needs to be defined explicitly with the arg element. The type attribute is required, since it will define the data type for the argument. Arguments are sometimes called parameters, when used with D-Bus methods. Each argument needs to specify the "direction" of the argument. Parameters for method calls are "going into" the service, hence the correct content for the direction attribute is in. Return values from method calls are "coming out" of the service. Hence, their direction will be out. If a method call does not return any value (returns void), then no argument with the direction out needs to be specified.

It should also be noted that D-Bus by itself does not limit the number of return arguments. C language supports only one return value from a function, but a lot of the higher level languages do not have this restriction.

The following argument types are supported for D-Bus methods (with respective closest types in GLib):


 * b: boolean (gboolean)
 * y: 8-bit unsigned integer (guint8)
 * q/n: 16-bit unsigned/signed integer (guint16/gint16)
 * u/i: 32-bit unsigned/signed integer (guint32/gint32)
 * t/x: 64-bit unsigned/signed integer (guint64/gint64)
 * d: IEEE 754 double precision floating point number (gdouble)
 * s: UTF-8 encoded text string with NUL termination (only one NUL allowed) (gchar* with additional restrictions)
 * a: Array of the following type specification (case-dependent)
 * o/g/r/(/)/v/e//: Complex types, please see the official D-Bus documentation on type signatures.

From the above list, it can be seen that setvalue1 will accept one 32-bit signed integer argument (new_value). The name of the argument will affect the generated stub code prototypes (not the implementation), but is quite useful for documentation, and also for D-Bus introspection (which will be covered later).

The next step is the interface specification of another method: getvalue1, which will return the current integer value of the object. It has no method call parameters (no arguments with direction="in"), and only returns one 32-bit signed integer: glib-dbus-sync/value-dbus-interface.xml

<tt>    <font color="#9A1900">&lt;!- getvalue1: returns the first value (int) -&gt;   <font color="#0000FF">&lt;method  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"getvalue1"   <font color="#0000FF">&gt;   <font color="#0000FF">&lt;arg  <font color="#009900">type  <font color="#990000"> =  <font color="#FF0000">"i"  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"cur_value"  <font color="#009900">direction  <font color="#990000"> =  <font color="#FF0000">"out"   <font color="#0000FF">/&gt;   <font color="#0000FF">&lt;/method&gt;  </tt>

Naming of the return arguments is also supported in D-Bus (as above). This will not influence the generated stub code, but serves as additional documentation.

The methods need to be bound to a specific (D-Bus) interface, and this is achieved by placing the method elements within an interface element. The interface name -attribute is optional, but very much recommended (otherwise the interface becomes unnamed, and provides less useful information on introspection).

Multiple interfaces can be implemented in the same object, and if this would be the case, the multiple interface elements would be listed within the node element. The node element is the "top-level" element in any case. In this case, only one explicit interface is implemented (the binding tools will add the introspection interfaces automatically, so specifying them is not necessary in the XML). And so, the result is the minimum required interface XML file: glib-dbus-sync/value-dbus-interface.xml

<tt>  <font color="#000080">&lt;?xml  <font color="#009900">version  <font color="#990000"> =  <font color="#FF0000">"1.0"  <font color="#009900">encoding  <font color="#990000"> =  <font color="#FF0000">"UTF-8"   <font color="#000080">?&gt;   <font color="#0000FF">&lt;node&gt;   <font color="#0000FF">&lt;interface  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"org.maemo.Value"   <font color="#0000FF">&gt;   <font color="#9A1900">&lt;!- getvalue1: returns the first value (int) -&gt;   <font color="#0000FF">&lt;method  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"getvalue1"   <font color="#0000FF">&gt;   <font color="#0000FF">&lt;arg  <font color="#009900">type  <font color="#990000"> =  <font color="#FF0000">"i"  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"cur_value"  <font color="#009900">direction  <font color="#990000"> =  <font color="#FF0000">"out"   <font color="#0000FF">/&gt;   <font color="#0000FF">&lt;/method&gt;   <font color="#9A1900">&lt;!- setvalue1(int newValue): sets value1 -&gt;   <font color="#0000FF">&lt;method  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"setvalue1"   <font color="#0000FF">&gt;   <font color="#0000FF">&lt;arg  <font color="#009900">type  <font color="#990000"> =  <font color="#FF0000">"i"  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"new_value"  <font color="#009900">direction  <font color="#990000"> =  <font color="#FF0000">"in"   <font color="#0000FF">/&gt;   <font color="#0000FF">&lt;/method&gt;   <font color="#0000FF">&lt;/interface&gt;   <font color="#0000FF">&lt;/node&gt;  </tt>

The minimal interface specification is then extended by adding the correct reference to the proper DTD. This will allow validation tools to work automatically with the XML file. Methods are also added to manipulate the second value. The full interface file will now contain comments, describing the purpose of the interface and the methods. This is highly recommended, if planning to publish the interface at some point, as the bare XML does not carry semantic information. glib-dbus-sync/value-dbus-interface.xml

<tt>  <font color="#000080">&lt;?xml  <font color="#009900">version  <font color="#990000"> =  <font color="#FF0000">"1.0"  <font color="#009900">encoding  <font color="#990000"> =  <font color="#FF0000">"UTF-8"   <font color="#000080">?&gt;   <font color="#9A1900">&lt;!- This maemo code example is licensed under a MIT-style license,   <font color="#9A1900">    that can be found in the file called "License" in the same  '' <font color="#9A1900">    directory as this file.   <font color="#9A1900">     Copyright (c) 2007-2008 Nokia Corporation. All rights reserved. -&gt; ''  <font color="#9A1900">&lt;!- If you keep the following DOCTYPE tag in your interface   <font color="#9A1900">    specification, xmllint can fetch the DTD over the Internet  '' <font color="#9A1900">    for validation automatically. -&gt; ''  <font color="#000080">&lt;!DOCTYPE  <font color="#009900">node  <font color="#009900">PUBLIC <font color="#FF0000">"-//freedesktop//DTD D-Bus Object Introspection 1.0//EN" <font color="#FF0000">"http://standards.freedesktop.org/dbus/1.0/introspect.dtd"  <font color="#000080">&gt;   <font color="#9A1900">&lt;!- This file defines the D-Bus interface for a simple object, that   <font color="#9A1900">    will hold a simple state consisting of two values (one a 32-bit   '' <font color="#9A1900">     integer, the other a double).   <font color="#9A1900">     '' '' <font color="#9A1900">    The interface name is "org.maemo.Value".   <font color="#9A1900">     One known reference implementation is provided for it by the ''  <font color="#9A1900">    "/GlobalValue" object found via a well-known name of  '' <font color="#9A1900">    "org.maemo.Platdev_ex". -&gt; ''  <font color="#0000FF">&lt;node&gt;   <font color="#0000FF">&lt;interface  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"org.maemo.Value"   <font color="#0000FF">&gt;   <font color="#9A1900">&lt;!- Method definitions -&gt;   <font color="#9A1900">&lt;!- getvalue1: returns the first value (int) -&gt;   <font color="#0000FF">&lt;method  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"getvalue1"   <font color="#0000FF">&gt;   <font color="#9A1900">&lt;!- NOTE Naming arguments is not mandatory, but is recommended  '' <font color="#9A1900">			    so that D-Bus introspection tools are more useful.   <font color="#9A1900">			     Otherwise the arguments will be automatically named '' '' <font color="#9A1900">			    "arg0", "arg1" and so on. -&gt; ''  <font color="#0000FF">&lt;arg  <font color="#009900">type  <font color="#990000"> =  <font color="#FF0000">"i"  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"cur_value"  <font color="#009900">direction  <font color="#990000"> =  <font color="#FF0000">"out"   <font color="#0000FF">/&gt;   <font color="#0000FF">&lt;/method&gt;   <font color="#9A1900">&lt;!- getvalue2: returns the second value (double) -&gt;   <font color="#0000FF">&lt;method  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"getvalue2"   <font color="#0000FF">&gt;   <font color="#0000FF">&lt;arg  <font color="#009900">type  <font color="#990000"> =  <font color="#FF0000">"d"  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"cur_value"  <font color="#009900">direction  <font color="#990000"> =  <font color="#FF0000">"out"   <font color="#0000FF">/&gt;   <font color="#0000FF">&lt;/method&gt;   <font color="#9A1900">&lt;!- setvalue1(int newValue): sets value1 -&gt;   <font color="#0000FF">&lt;method  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"setvalue1"   <font color="#0000FF">&gt;   <font color="#0000FF">&lt;arg  <font color="#009900">type  <font color="#990000"> =  <font color="#FF0000">"i"  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"new_value"  <font color="#009900">direction  <font color="#990000"> =  <font color="#FF0000">"in"   <font color="#0000FF">/&gt;   <font color="#0000FF">&lt;/method&gt;   <font color="#9A1900">&lt;!- setvalue2(double newValue): sets value2 -&gt;   <font color="#0000FF">&lt;method  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"setvalue2"   <font color="#0000FF">&gt;   <font color="#0000FF">&lt;arg  <font color="#009900">type  <font color="#990000"> =  <font color="#FF0000">"d"  <font color="#009900">name  <font color="#990000"> =  <font color="#FF0000">"new_value"  <font color="#009900">direction  <font color="#990000"> =  <font color="#FF0000">"in"   <font color="#0000FF">/&gt;   <font color="#0000FF">&lt;/method&gt;   <font color="#0000FF">&lt;/interface&gt;   <font color="#0000FF">&lt;/node&gt;  </tt>

When dealing with automatic code generation, it is quite useful to also automate testing of the "source files" (in this case, XML). One important validation technique for XML is verifying for well-formedness (all XML files need to satisfy the rules in XML spec 1.0). Another is validating the structure of XML (that elements are nested correctly, that only correct elements are present and that the element attributes and data are legal). Structural validation rules are described by a DTD (Document Type Definition) document for the XML format that the file is supposed to adhere to. The DTD is specified in the XML, within the DOCTYPE processing directive.

This is still not perfect, as DTD validation can only check for syntax and structure, but not meaning or semantics.

The next step is to add a target called checkxml to the Makefile, so that it can be run whenever the validity of the interface XML is to be checked. glib-dbus-sync/Makefile

<tt>  <font color="#9A1900"> # One extra target (which requires xmllint, from package libxml2-utils)   <font color="#9A1900"> # is available to verify the well-formedness and the structure of the  '' <font color="#9A1900"> # interface definition xml file.   <font color="#9A1900"> # ''  <font color="#9A1900"> # Use the 'checkxml' target to run the interface XML through xmllint  '' <font color="#9A1900"> # verification. You will need to be connected to the Internet in order ''  <font color="#9A1900"> # for xmllint to retrieve the DTD from fd.o (unless you setup local  '' <font color="#9A1900"> # catalogs, which are not covered here).   <font color="#9A1900"> # ... Listing cut for brevity ...   <font color="#9A1900"> # Interface XML name (used in multiple targets) '' interface_xml <font color="#990000"> := value-dbus-interface <font color="#990000">. xml '' <font color="#9A1900"> # ... Listing cut for brevity ...   <font color="#9A1900"> # Special target to run DTD validation on the interface XML. Not run ''  <font color="#9A1900"> # automatically (since xmllint is not always available and also needs  '' <font color="#9A1900"> # Internet connectivity). '' checkxml <font color="#990000"> :  <font color="#009900">$(interface_xml) @xmllint -valid -noout <font color="#009900">$&lt; @echo <font color="#009900">$&lt; checks out ok </tt>

[sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; make checkxml value-dbus-interface.xml checks out ok

Just to demonstrate what kind of error messages to expect when there are problems in the XML, the valid interface specification is modified slightly by adding one invalid element (invalidElement), and by removing one starting tag (method).

[sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; make checkxml value-dbus-interface.xml:36: element invalidElement: validity error : No declaration for element invalidElement &lt;/invalidElement&gt; ^ value-dbus-interface.xml:53: parser error : Opening and ending tag mismatch: method line 39 and interface &lt;/interface&gt; ^ value-dbus-interface.xml:54: parser error : Opening and ending tag mismatch: interface line 22 and node &lt;/node&gt; ^ value-dbus-interface.xml:55: parser error : Premature end of data in tag node line 21 ^ make: *** [checkxml] Error 1

The first error (validity error) is detected, because the file does not adhere to the DTD. The other errors (parser errors) are detected, because the file is no longer a well-formed XML document.

If the makefile targets depend on checkxml, the validation can be integrated into the process of the build. However, as was noted before, it might not be always the best solution.

Generating Automatic Stub Code
Now the following step is to generate the "glue" code that will implement the mapping from GLib into D-Bus. The generated code will be used later on, but it is instructive to see what the dbus-binding-tool program generates.

The Makefile will be expanded to invoke the tool whenever the interface XML changes, and store the resulting glue code separately for both the client and server. glib-dbus-sync/Makefile

<tt>  <font color="#9A1900"> # Define a list of generated files so that they can be cleaned as well  cleanfiles <font color="#990000"> := value-client-stub <font color="#990000">. h <font color="#990000">\ value-server-stub <font color="#990000">. h '' <font color="#9A1900"> # ... Listing cut for brevity ...   <font color="#9A1900"> # If the interface XML changes, the respective stub interfaces will be '' '' <font color="#9A1900"> # automatically regenerated. Normally this would also mean that your ''  <font color="#9A1900"> # builds would fail after this since you would be missing implementation  '' <font color="#9A1900"> # code. '' value-server-stub <font color="#990000">. h <font color="#990000"> : <font color="#009900">$(interface_xml) dbus-binding-tool -prefix <font color="#990000"> = value_object -mode <font color="#990000"> = glib-server <font color="#990000">\ <font color="#009900">$&lt; <font color="#990000">&gt;  <font color="#009900">$@ value-client-stub <font color="#990000">. h <font color="#990000"> : <font color="#009900">$(interface_xml) dbus-binding-tool -prefix <font color="#990000"> = value_object -mode <font color="#990000"> = glib-client <font color="#990000">\ <font color="#009900">$&lt; <font color="#990000">&gt;  <font color="#009900">$@ '' <font color="#9A1900"> # ... Listing cut for brevity ... '' clean <font color="#990000"> : <font color="#009900">$(RM) <font color="#009900">$(targets)  <font color="#009900">$(cleanfiles)  <font color="#990000"> *. o </tt>

Two parameters are passed for the dbus-binding-tool program. The  parameter is used to tell what text should be prefixed to all generated structure and function names. This will help avoid namespace collisions, when pulling the generated glue files back into the programs. The value_object will be used, since it seems like a logical prefix for the project. It is advisable to use a prefix that is not used in the code (even in the object implementation in server). This way, there is no risk of reusing the same names that are generated with the tool.

The second parameter will select what kind of output the tool will generate. At the moment, the tool only supports generating GLib/D-Bus bindings, but this might change in the future. Also, it is necessary to select which "side" of the D-Bus the bindings will be generated for. The -client side is for code that wishes to use GLib to access the Value object implementation over D-Bus. The -server side is respectively for the implementation of the Value object.

Running the tool will result in the two header files:

[sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; make value-server-stub.h value-client-stub.h dbus-binding-tool --prefix=value_object --mode=glib-server \ value-dbus-interface.xml &gt; value-server-stub.h dbus-binding-tool --prefix=value_object --mode=glib-client \ value-dbus-interface.xml &gt; value-client-stub.h [sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; ls -la value*stub.h -rw-rw-r-- 1 user user 5184 Nov 21 14:02 value-client-stub.h -rw-rw-r-- 1 user user 10603 Nov 21 14:02 value-server-stub.h

The object implementation will be handled in a bit, but first it should be checked what the tool produced, starting with the server stub file: glib-dbus-sync/value-server-stub.h

<tt> '' <font color="#9A1900">/* Generated by dbus-binding-tool; do not edit! */     <font color="#9A1900">/*... Listing cut for brevity ...*/ ''  <font color="#000080"> #include  <font color="#FF0000">&lt;dbus/dbus-glib.h&gt;  <font color="#0000FF">static   <font color="#0000FF">const  DBusGMethodInfo dbus_glib_value_object_methods <font color="#990000">[]  <font color="#990000"> =  <font color="#FF0000">{ <font color="#FF0000">{ <font color="#990000">( GCallback <font color="#990000">) value_object_getvalue1 <font color="#990000">, dbus_glib_marshal_value_object_BOOLEAN__POINTER_POINTER <font color="#990000">, <font color="#993399">0  <font color="#FF0000">}  <font color="#990000">, <font color="#FF0000">{ <font color="#990000">( GCallback <font color="#990000">) value_object_getvalue2 <font color="#990000">, dbus_glib_marshal_value_object_BOOLEAN__POINTER_POINTER <font color="#990000">, <font color="#993399">47  <font color="#FF0000">}  <font color="#990000">, <font color="#FF0000">{ <font color="#990000">( GCallback <font color="#990000">) value_object_setvalue1 <font color="#990000">, dbus_glib_marshal_value_object_BOOLEAN__INT_POINTER <font color="#990000">, <font color="#993399">94  <font color="#FF0000">}  <font color="#990000">, <font color="#FF0000">{ <font color="#990000">( GCallback <font color="#990000">) value_object_setvalue2 <font color="#990000">, dbus_glib_marshal_value_object_BOOLEAN__DOUBLE_POINTER <font color="#990000">, <font color="#993399">137  <font color="#FF0000">}  <font color="#990000">, <font color="#FF0000">} <font color="#990000"> ;  <font color="#0000FF">const  DBusGObjectInfo dbus_glib_value_object_object_info <font color="#990000"> = <font color="#FF0000">{ <font color="#993399">0 <font color="#990000">, dbus_glib_value_object_methods <font color="#990000">, <font color="#993399">4 <font color="#990000">, <font color="#FF0000">"org.maemo.Value <font color="#CC33CC">\0  <font color="#FF0000">getvalue1  <font color="#CC33CC">\0  <font color="#FF0000">S  <font color="#CC33CC">\0  <font color="#FF0000">cur_value  <font color="#CC33CC">\0  <font color="#FF0000">O  <font color="#CC33CC">\0  <font color="#FF0000">F  <font color="#CC33CC">\0  <font color="#FF0000">N  <font color="#CC33CC">\0  <font color="#FF0000">i  <font color="#CC33CC">\0\0  <font color="#FF0000">" <font color="#FF0000">"org.maemo.Value <font color="#CC33CC">\0  <font color="#FF0000">getvalue2  <font color="#CC33CC">\0  <font color="#FF0000">S  <font color="#CC33CC">\0  <font color="#FF0000">cur_value  <font color="#CC33CC">\0  <font color="#FF0000">O  <font color="#CC33CC">\0  <font color="#FF0000">F  <font color="#CC33CC">\0  <font color="#FF0000">N  <font color="#CC33CC">\0  <font color="#FF0000">d  <font color="#CC33CC">\0\0  <font color="#FF0000">" <font color="#FF0000">"org.maemo.Value <font color="#CC33CC">\0  <font color="#FF0000">setvalue1  <font color="#CC33CC">\0  <font color="#FF0000">S  <font color="#CC33CC">\0  <font color="#FF0000">new_value  <font color="#CC33CC">\0  <font color="#FF0000">I  <font color="#CC33CC">\0  <font color="#FF0000">i  <font color="#CC33CC">\0\0  <font color="#FF0000">" <font color="#FF0000">"org.maemo.Value <font color="#CC33CC">\0  <font color="#FF0000">setvalue2  <font color="#CC33CC">\0  <font color="#FF0000">S  <font color="#CC33CC">\0  <font color="#FF0000">new_value  <font color="#CC33CC">\0  <font color="#FF0000">I  <font color="#CC33CC">\0  <font color="#FF0000">d  <font color="#CC33CC">\0\0\0  <font color="#FF0000">"  <font color="#990000">, <font color="#FF0000">" <font color="#CC33CC">\0  <font color="#FF0000">"  <font color="#990000">, <font color="#FF0000">" <font color="#CC33CC">\0  <font color="#FF0000">" <font color="#FF0000">} <font color="#990000"> ; </tt>

The interest here lies in the method table, mainly because it lists the names of the functions that are needed to be implemented: value_object_getvalue1, 0_object_getvalue2, value_object_setvalue1 and value_object_setvalue2. Each entry in the table consists of a function address, and the function to use to marshal data from/to GLib/D-Bus (the functions that start with dbus_glib_marshal_*). The marshaling functions are defined in the same file, but were omitted from the listing above.

Marshaling in its most generic form means the conversion of parameters or arguments from one format to another, in order to make two different parameter passing conventions compatible. It is a common feature found in almost all RPC mechanisms. Since GLib has its own type system (which will be shown shortly) and D-Bus its own, it would be very tedious to write the conversion code manually. This is where the binding generation tool really helps.

The other interesting feature of the above listing is the _object_info structure. It will be passed to the D-Bus daemon, when the object is ready to be published on the bus (so that clients may invoke methods on it). The very long string (that contains binary zeroes) is the compact format of the interface specification. Similarities can be seen between the names in the string and the names of the interface, methods and arguments that were declared in the XML. It is also an important part of the D-Bus introspection mechanism, which will be covered at the end of this chapter.

As the snippet says at the very first line, it should never be edited manually. This holds true while using the XML file as the source of an interface. It is also possible to use the XML only once, when starting the project, and then just start copy-pasting the generated glue code around, while discarding the XML file and dbus-binding-tool. Needless to say, this makes maintenance of the interface much more difficult and is not really recommended. The generated stub code will not be edited in this material.

The example will next continue with the server implementation for the functions that are called via the method table.

Creating Simple GObject for D-Bus
The starting point here is with the per-instance and per-class state structures for the object. The per-class structure contains only the bare minimum contents, which are required from all classes in GObject. The per-instance structure contains the required "parent object" state (GObject), but also includes the two internal values (value1 and value2), with which the rest of this example will be concerned: glib-dbus-sync/server.c

<tt> '' <font color="#9A1900">/* This defines the per-instance state.   <font color="#9A1900">   Each GObject must start with the 'parent' definition so that common '' '' <font color="#9A1900">  operations that all GObjects support can be called on it. */ ''  <font color="#0000FF">typedef    <font color="#0000FF">struct   <font color="#FF0000">{ '' <font color="#9A1900">/* The parent class object state. */ ''   GObject parent <font color="#990000"> ; '' <font color="#9A1900">/* Our first per-object state variable. */ ''   gint value1 <font color="#990000"> ; '' <font color="#9A1900">/* Our second per-object state variable. */ ''   gdouble value2 <font color="#990000"> ; <font color="#FF0000">} ValueObject <font color="#990000"> ; '' <font color="#9A1900">/* Per class state.   <font color="#9A1900">   For the first Value implementation we only have the bare minimum, '' '' <font color="#9A1900">  that is, the common implementation for any GObject class. */ ''  <font color="#0000FF">typedef    <font color="#0000FF">struct   <font color="#FF0000">{ '' <font color="#9A1900">/* The parent class state. */ ''   GObjectClass parent <font color="#990000"> ; <font color="#FF0000">} ValueObjectClass <font color="#990000"> ; </tt>

Then convenience macros will be defined in a way expected for all GTypes. The G_TYPE_-macros are defined in GType, and include the magic by which the object implementation does not need to know much about the internal specifics of GType. The GType macros are described in the GObject API reference for GType.

Some of the macros will be used internally in this implementation later on. glib-dbus-sync/server.c

<tt>  <font color="#9A1900">/* Forward declaration of the function that will return the GType of  '' <font color="#9A1900">  the Value implementation. Not used in this program since we only '' '' <font color="#9A1900">  need to push this over the D-Bus. */ '' GType  <font color="#000000">value_object_get_type   <font color="#990000">(  <font color="#009900">void  <font color="#990000">); '' <font color="#9A1900">/* Macro for the above. It is common to define macros using the ''  <font color="#9A1900">  naming convention (seen below) for all GType implementations,  '' <font color="#9A1900">  and that is why we are going to do that here as well. */ ''  <font color="#000080"> #define    <font color="#000000">VALUE_TYPE_OBJECT   <font color="#990000">(   <font color="#000000">value_object_get_type   <font color="#990000">)  <font color="#000080"> #define   <font color="#000000">VALUE_OBJECT   <font color="#990000">( object <font color="#990000">)  <font color="#990000">\ <font color="#990000">(  <font color="#000000">G_TYPE_CHECK_INSTANCE_CAST   <font color="#990000">(( object <font color="#990000">),  <font color="#990000">\ VALUE_TYPE_OBJECT <font color="#990000">, ValueObject <font color="#990000">))  <font color="#000080"> #define   <font color="#000000">VALUE_OBJECT_CLASS   <font color="#990000">( klass <font color="#990000">)  <font color="#990000">\ <font color="#990000">(  <font color="#000000">G_TYPE_CHECK_CLASS_CAST   <font color="#990000">(( klass <font color="#990000">),  <font color="#990000">\ VALUE_TYPE_OBJECT <font color="#990000">, ValueObjectClass <font color="#990000">))  <font color="#000080"> #define   <font color="#000000">VALUE_IS_OBJECT   <font color="#990000">( object <font color="#990000">)  <font color="#990000">\ <font color="#990000">(  <font color="#000000">G_TYPE_CHECK_INSTANCE_TYPE   <font color="#990000">(( object <font color="#990000">),  <font color="#990000">\ VALUE_TYPE_OBJECT <font color="#990000">))  <font color="#000080"> #define   <font color="#000000">VALUE_IS_OBJECT_CLASS   <font color="#990000">( klass <font color="#990000">)  <font color="#990000">\ <font color="#990000">(  <font color="#000000">G_TYPE_CHECK_CLASS_TYPE   <font color="#990000">(( klass <font color="#990000">),  <font color="#990000">\ VALUE_TYPE_OBJECT <font color="#990000">))  <font color="#000080"> #define   <font color="#000000">VALUE_OBJECT_GET_CLASS   <font color="#990000">( obj <font color="#990000">)  <font color="#990000">\ <font color="#990000">(  <font color="#000000">G_TYPE_INSTANCE_GET_CLASS   <font color="#990000">(( obj <font color="#990000">),  <font color="#990000">\ VALUE_TYPE_OBJECT <font color="#990000">, ValueObjectClass <font color="#990000">)) '' <font color="#9A1900">/* Utility macro to define the value_object GType structure. */ ''  <font color="#000000">G_DEFINE_TYPE   <font color="#990000">( ValueObject <font color="#990000">, value_object <font color="#990000">, G_TYPE_OBJECT <font color="#990000">) </tt>

After the macros, the next phase cpntains the instance initialization and class initialization functions, of which the class initialization function contains the integration call into GLib/D-Bus: glib-dbus-sync/server.c

<tt>  <font color="#9A1900">/**   <font color="#9A1900"> * Since the stub generator will reference the functions from a call  '' <font color="#9A1900"> * table, the functions must be declared before the stub is included.   <font color="#9A1900"> */ '' gboolean  <font color="#000000">value_object_getvalue1  <font color="#990000">( ValueObject <font color="#990000"> * obj <font color="#990000">, gint <font color="#990000"> * value_out <font color="#990000">,                                                    GError <font color="#990000"> ** error <font color="#990000">); gboolean  <font color="#000000">value_object_getvalue2  <font color="#990000">( ValueObject <font color="#990000"> * obj <font color="#990000">, gdouble <font color="#990000"> * value_out <font color="#990000">,                                                    GError <font color="#990000"> ** error <font color="#990000">); gboolean  <font color="#000000">value_object_setvalue1  <font color="#990000">( ValueObject <font color="#990000"> * obj <font color="#990000">, gint value_in <font color="#990000">,                                                    GError <font color="#990000"> ** error <font color="#990000">); gboolean  <font color="#000000">value_object_setvalue2  <font color="#990000">( ValueObject <font color="#990000"> * obj <font color="#990000">, gdouble value_in <font color="#990000">,                                                    GError <font color="#990000"> ** error <font color="#990000">);  <font color="#9A1900">/**  '' <font color="#9A1900"> * Pull in the stub for the server side.   <font color="#9A1900"> */ ''  <font color="#000080"> #include  <font color="#FF0000">"value-server-stub.h"    '' <font color="#9A1900">/*... Listing cut for brevity ...*/ ''  <font color="#9A1900">/**   <font color="#9A1900"> * Per object initializer   <font color="#9A1900"> *   <font color="#9A1900"> * Only sets up internal state (both values set to zero)   <font color="#9A1900"> */   <font color="#0000FF">static  <font color="#009900">void   <font color="#000000">value_object_init   <font color="#990000">( ValueObject <font color="#990000"> * obj <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">dbg  <font color="#990000">(  <font color="#FF0000">"Called"  <font color="#990000">);  <font color="#000000">g_assert  <font color="#990000">( obj <font color="#990000"> != NULL <font color="#990000">); obj <font color="#990000">-&gt; value1 <font color="#990000"> = <font color="#993399">0  <font color="#990000"> ; obj <font color="#990000">-&gt; value2 <font color="#990000"> = <font color="#993399">0.0  <font color="#990000"> ; <font color="#FF0000">}  <font color="#9A1900">/**   <font color="#9A1900"> * Per class initializer   <font color="#9A1900"> *   <font color="#9A1900"> * Registers the type into the GLib/D-Bus wrapper so that it may add  '' <font color="#9A1900"> * its own magic.   <font color="#9A1900"> */ ''  <font color="#0000FF">static  <font color="#009900">void   <font color="#000000">value_object_class_init   <font color="#990000">( ValueObjectClass <font color="#990000"> * klass <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">dbg  <font color="#990000">(  <font color="#FF0000">"Called"  <font color="#990000">);  <font color="#000000">g_assert  <font color="#990000">( klass <font color="#990000"> != NULL <font color="#990000">);  <font color="#000000">dbg  <font color="#990000">(  <font color="#FF0000">"Binding to GLib/D-Bus"  <font color="#990000">); '' <font color="#9A1900">/* Time to bind this GType into the GLib/D-Bus wrappers.   <font color="#9A1900">     NOTE: This is not yet "publishing" the object on the D-Bus, but ''  <font color="#9A1900">          since it is only allowed to do this once per class   <font color="#9A1900">          creation, the safest place to put it is in the class  '' <font color="#9A1900">          initializer.   <font color="#9A1900">           Specifically, this function adds "method introspection    <font color="#9A1900">           data" to the class so that methods can be called over '' '' <font color="#9A1900">          the D-Bus. */ ''    <font color="#000000">dbus_g_object_type_install_info   <font color="#990000">( VALUE_TYPE_OBJECT <font color="#990000">,                                   <font color="#990000">&amp; dbus_glib_value_object_object_info <font color="#990000">);  <font color="#000000">dbg  <font color="#990000">(  <font color="#FF0000">"Done"  <font color="#990000">); '' <font color="#9A1900">/* All done. Class is ready to be used for instantiating objects */ '' <font color="#FF0000">} </tt>

The dbus_g_object_type_install_info will take a pointer to the structure describing the D-Bus integration (dbus_glib_value_object_object_info), which is generated by dbus-bindings-tool. This function will create all the necessary runtime information for the GType, so the details can be left alone. It will also attach the introspection data to the GType, so that D-Bus introspection may return information on the interface that the object will implement.

The next functions to be implemented are the get and set functions, which allow us to inspect the interface as well. N.B. The names of the functions and their prototypes are ultimately dictated by dbus-bindings-tool generated stub header files. This means that if the interface XML is sufficiently changed, the code will fail to build (since the generated stubs will yield different prototypes): glib-dbus-sync/server.c

<tt>  <font color="#9A1900">/**   <font color="#9A1900"> * Function that gets called when someone tries to execute "setvalue1"  '' <font color="#9A1900"> * over the D-Bus. (Actually the marshaling code from the stubs gets   <font color="#9A1900"> * executed first, but they will eventually execute this function.) ''  <font color="#9A1900"> *   <font color="#9A1900"> * NOTE: If you change the name of this function, the generated  '' <font color="#9A1900"> *      stubs will no longer find it! On the other hand, if you ''  <font color="#9A1900"> *      decide to modify the interface XML, this is one of the places  '' <font color="#9A1900"> *      that you will have to modify as well.   <font color="#9A1900"> *       This applies to the next four functions (including this one).   <font color="#9A1900"> */ '' gboolean  <font color="#000000">value_object_setvalue1  <font color="#990000">( ValueObject <font color="#990000"> * obj <font color="#990000">, gint valueIn <font color="#990000">,                                                    GError <font color="#990000"> ** error <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">dbg  <font color="#990000">(  <font color="#FF0000">"Called (valueIn=%d)"  <font color="#990000">, valueIn <font color="#990000">);  <font color="#000000">g_assert  <font color="#990000">( obj <font color="#990000"> != NULL <font color="#990000">); '' <font color="#9A1900">/* Change the value. */ ''   obj <font color="#990000">-&gt; value1 <font color="#990000"> = valueIn <font color="#990000"> ; '' <font color="#9A1900">/* Return success to GLib/D-Bus wrappers. In this case we do not need '' '' <font color="#9A1900">    to touch the supplied error pointer-pointer. */ ''    <font color="#0000FF">return  TRUE <font color="#990000"> ; <font color="#FF0000">}  <font color="#9A1900">/**  '' <font color="#9A1900"> * Function that gets executed on "setvalue2".   <font color="#9A1900"> * Other than this function operating with different type input ''  <font color="#9A1900"> * parameter (and different internal value), all the comments from  '' <font color="#9A1900"> * set_value1 apply here as well.   <font color="#9A1900"> */ '' gboolean  <font color="#000000">value_object_setvalue2  <font color="#990000">( ValueObject <font color="#990000"> * obj <font color="#990000">, gdouble valueIn <font color="#990000">,                                                    GError <font color="#990000"> ** error <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">dbg  <font color="#990000">(  <font color="#FF0000">"Called (valueIn=%.3f)"  <font color="#990000">, valueIn <font color="#990000">);  <font color="#000000">g_assert  <font color="#990000">( obj <font color="#990000"> != NULL <font color="#990000">); obj <font color="#990000">-&gt; value2 <font color="#990000"> = valueIn <font color="#990000"> ;  <font color="#0000FF">return  TRUE <font color="#990000"> ; <font color="#FF0000">}  <font color="#9A1900">/**  '' <font color="#9A1900"> * Function that gets executed on "getvalue1".   <font color="#9A1900"> */ '' gboolean  <font color="#000000">value_object_getvalue1  <font color="#990000">( ValueObject <font color="#990000"> * obj <font color="#990000">, gint <font color="#990000"> * valueOut <font color="#990000">,                                                    GError <font color="#990000"> ** error <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">dbg  <font color="#990000">(  <font color="#FF0000">"Called (internal value1 is %d)"  <font color="#990000">, obj <font color="#990000">-&gt; value1 <font color="#990000">);  <font color="#000000">g_assert  <font color="#990000">( obj <font color="#990000"> != NULL <font color="#990000">); '' <font color="#9A1900">/* Check that the target pointer is not NULL.   <font color="#9A1900">     Even is the only caller for this will be the GLib-wrapper code, ''  <font color="#9A1900">    we cannot trust the stub generated code and should handle the  '' <font color="#9A1900">    situation. We will terminate with an error in this case.   <font color="#9A1900">     Another option would be to create a new GError, and store '' '' <font color="#9A1900">    the error condition there. */ ''    <font color="#000000">g_assert   <font color="#990000">( valueOut <font color="#990000"> != NULL <font color="#990000">); '' <font color="#9A1900">/* Copy the current first value to caller specified memory. */ ''   <font color="#990000"> * valueOut <font color="#990000"> = obj <font color="#990000">-&gt; value1 <font color="#990000"> ; '' <font color="#9A1900">/* Return success. */ ''    <font color="#0000FF">return  TRUE <font color="#990000"> ; <font color="#FF0000">}  <font color="#9A1900">/**  '' <font color="#9A1900"> * Function that gets executed on "getvalue2".   <font color="#9A1900"> * (Again, similar to "getvalue1").   <font color="#9A1900"> */ '' gboolean  <font color="#000000">value_object_getvalue2  <font color="#990000">( ValueObject <font color="#990000"> * obj <font color="#990000">, gdouble <font color="#990000"> * valueOut <font color="#990000">,                                                    GError <font color="#990000"> ** error <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">dbg  <font color="#990000">(  <font color="#FF0000">"Called (internal value2 is %.3f)"  <font color="#990000">, obj <font color="#990000">-&gt; value2 <font color="#990000">);  <font color="#000000">g_assert  <font color="#990000">( obj <font color="#990000"> != NULL <font color="#990000">);  <font color="#000000">g_assert  <font color="#990000">( valueOut <font color="#990000"> != NULL <font color="#990000">); <font color="#990000"> * valueOut <font color="#990000"> = obj <font color="#990000">-&gt; value2 <font color="#990000"> ;  <font color="#0000FF">return  TRUE <font color="#990000"> ; <font color="#FF0000">} </tt>

The GLib/D-Bus wrapper logic will implement all of the parameter conversion necessary from D-Bus into the functions, so it is only necessary to handle the GLib corresponding types (gint and gdouble). The method implementations will always receive an object reference to the object as their first parameter, and a pointer to a place where to store new GError objects if the method decides an error should be created. This error would then be propagated back to the caller of the D-Bus method. This simple get/set examples will never set errors, so the last parameter can be ignored here.

N.B. Returning the values is not performed via the conventional C way (by using return someVal), but instead return values are written via the given pointers. The return value of the method is always a gboolean, signifying either success or failure. If failure (FALSE) is returned, it is also necessary to create and setup an GError object, and store its address to the error location.

Publishing GType on D-Bus
Once the implementation is complete, it will be necessary to publish an instance of the class onto the D-Bus. This will be done inside the main of the server example, and involves performing a D-Bus method call on the bus.

So that both the server and client do not have to be changed, if the object or well-known names are changed later, they are put into a common header file that will be used by both: glib-dbus-sync/common-defs.h

<tt> '' <font color="#9A1900">/* Well-known name for this service. */ ''  <font color="#000080"> #define  VALUE_SERVICE_NAME        <font color="#FF0000">"org.maemo.Platdev_ex" '' <font color="#9A1900">/* Object path to the provided object. */ ''  <font color="#000080"> #define  VALUE_SERVICE_OBJECT_PATH <font color="#FF0000">"/GlobalValue" '' <font color="#9A1900">/* And we're interested in using it through this interface.   <font color="#9A1900">   This must match the entry in the interface definition XML. */ ''  <font color="#000080"> #define  VALUE_SERVICE_INTERFACE   <font color="#FF0000">"org.maemo.Value" </tt>

The decision to use /GlobalValue as the object path is based on clarity only. Most of the time something like /org/maemo/Value would be used instead.

Before using any of the GType functions, it is necessary to initialize the runtime system by calling g_type_init. This will create the built-in types and set-up all the machinery necessary for creating custom types as well. When using GTK+, the function is called automatically, when initializing GTK+. Since this example only uses GLib, it is necessary to call the function manually.

After initializing the GType system, the next step is to open a connection to the session bus, which will be used for the remainder of the publishing sequence: glib-dbus-sync/server.c

<tt>  <font color="#9A1900">/* Pull symbolic constants that are shared (in this example) between  '' <font color="#9A1900">  the client and the server. */   <font color="#000080"> #include   <font color="#FF0000">"common-defs.h"     <font color="#9A1900">/*... Listing cut for brevity ...*/ '' <font color="#009900">int  <font color="#000000">main   <font color="#990000">(  <font color="#009900">int argc <font color="#990000">,  <font color="#009900">char  <font color="#990000"> ** argv <font color="#990000">)  <font color="#FF0000">{ '' <font color="#9A1900">/*... Listing cut for brevity ...*/ '' '' <font color="#9A1900">/* Initialize the GType/GObject system. */ ''    <font color="#000000">g_type_init   <font color="#990000">; '' <font color="#9A1900">/*... Listing cut for brevity ...*/ ''  <font color="#000000">g_print  <font color="#990000">( PROGNAME <font color="#FF0000">":main Connecting to the Session D-Bus.  <font color="#CC33CC">\n  <font color="#FF0000">"  <font color="#990000">); bus <font color="#990000"> =  <font color="#000000">dbus_g_bus_get   <font color="#990000">( DBUS_BUS_SESSION <font color="#990000">,  <font color="#990000">&amp; error <font color="#990000">);  <font color="#0000FF">if  <font color="#990000">( error <font color="#990000"> != NULL <font color="#990000">)  <font color="#FF0000">{ '' <font color="#9A1900">/* Print error and terminate. */ ''      <font color="#000000">handleError   <font color="#990000">(  <font color="#FF0000">"Could not connect to session bus"  <font color="#990000">, error <font color="#990000">-&gt; message <font color="#990000">, TRUE <font color="#990000">); <font color="#FF0000">} </tt>

In order for prospective clients to find the object on the session bus, it is necessary to attach the server to a well-known name. This is done with the RequestName method call on the D-Bus server (over D-Bus). In order to target the server, it is necessary to create a GLib/D-Bus proxy object first: glib-dbus-sync/server.c

<tt>  <font color="#000000">g_print   <font color="#990000">( PROGNAME <font color="#FF0000">":main Registering the well-known name (%s)  <font color="#CC33CC">\n  <font color="#FF0000">"  <font color="#990000">,            VALUE_SERVICE_NAME <font color="#990000">);  <font color="#9A1900">/* In order to register a well-known name, we need to use the  '' <font color="#9A1900">    "RequestMethod" of the /org/freedesktop/DBus interface. Each '' '' <font color="#9A1900">    bus provides an object that will implement this interface.   <font color="#9A1900">     In order to do the call, we need a proxy object first.   <font color="#9A1900">     DBUS_SERVICE_DBUS = "org.freedesktop.DBus" ''  <font color="#9A1900">    DBUS_PATH_DBUS = "/org/freedesktop/DBus"   <font color="#9A1900">    DBUS_INTERFACE_DBUS = "org.freedesktop.DBus" */  busProxy <font color="#990000"> =  <font color="#000000">dbus_g_proxy_new_for_name   <font color="#990000">( bus <font color="#990000">,                                         DBUS_SERVICE_DBUS <font color="#990000">,                                         DBUS_PATH_DBUS <font color="#990000">,                                         DBUS_INTERFACE_DBUS <font color="#990000">);  <font color="#0000FF">if  <font color="#990000">( busProxy <font color="#990000"> == NULL <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">handleError  <font color="#990000">(  <font color="#FF0000">"Failed to get a proxy for D-Bus"  <font color="#990000">,                  <font color="#FF0000">"Unknown(dbus_g_proxy_new_for_name)"  <font color="#990000">, TRUE <font color="#990000">); <font color="#FF0000">} '' <font color="#9A1900">/* Attempt to register the well-known name.   <font color="#9A1900">     The RPC call requires two parameters: ''  <font color="#9A1900">    - arg0: (D-Bus STRING): name to request  '' <font color="#9A1900">    - arg1: (D-Bus UINT32): flags for registration.   <font color="#9A1900">       (please see "org.freedesktop.DBus.RequestName" in    <font color="#9A1900">            <font color="#0000FF">http://dbus.freedesktop.org/doc/dbus-specification.html     <font color="#9A1900">) '' '' <font color="#9A1900">    Will return one uint32 giving the result of the RPC call.   <font color="#9A1900">     We are interested in 1 (we are now the primary owner of the name) ''  <font color="#9A1900">    or 4 (we were already the owner of the name, however in this   '' <font color="#9A1900">     application it would not make much sense).   <font color="#9A1900">     The function will return FALSE if it sets the GError. */ ''    <font color="#0000FF">if   <font color="#990000">(!   <font color="#000000">dbus_g_proxy_call   <font color="#990000">( busProxy <font color="#990000">, '' <font color="#9A1900">/* Method name to call. */ ''                          <font color="#FF0000">"RequestName"  <font color="#990000">, '' <font color="#9A1900">/* Where to store the GError. */ ''                          <font color="#990000">&amp; error <font color="#990000">, '' <font color="#9A1900">/* Parameter type of argument 0. Note that ''  <font color="#9A1900">                           since we are dealing with GLib/D-Bus   <font color="#9A1900">                           wrappers, you will need to find a suitable   <font color="#9A1900">                           GType instead of using the "native" D-Bus  '' <font color="#9A1900">                           type codes. */ ''                          G_TYPE_STRING <font color="#990000">, '' <font color="#9A1900">/* Data of argument 0. In our case, this is ''  <font color="#9A1900">                           the well-known name for our server  '' <font color="#9A1900">                           example ("org.maemo.Platdev_ex"). */ ''                          VALUE_SERVICE_NAME <font color="#990000">, '' <font color="#9A1900">/* Parameter type of argument 1. */ ''                          G_TYPE_UINT <font color="#990000">, '' <font color="#9A1900">/* Data of argument 0. This is the "flags" ''  <font color="#9A1900">                           argument of the "RequestName" method which   <font color="#9A1900">                           can be use to specify what the bus service   <font color="#9A1900">                           should do when the name already exists on  '' <font color="#9A1900">                           the bus. We will go with defaults. */ ''                          <font color="#993399">0  <font color="#990000">,  <font color="#9A1900">/* Input arguments are terminated with a  '' <font color="#9A1900">                           special GType marker. */ ''                          G_TYPE_INVALID <font color="#990000">, '' <font color="#9A1900">/* Parameter type of return value 0.   <font color="#9A1900">                            For "RequestName" it is UINT32 so we pick ''  <font color="#9A1900">                           the GType that maps into UINT32 in the  '' <font color="#9A1900">                           wrappers. */ ''                          G_TYPE_UINT <font color="#990000">, '' <font color="#9A1900">/* Data of return value 0. These will always ''  <font color="#9A1900">                           be pointers to the locations where the  '' <font color="#9A1900">                           proxy can copy the results. */ ''                          <font color="#990000">&amp; result <font color="#990000">, '' <font color="#9A1900">/* Terminate list of return values. */ ''                          G_TYPE_INVALID <font color="#990000">))  <font color="#FF0000">{  <font color="#000000">handleError  <font color="#990000">(  <font color="#FF0000">"D-Bus.RequestName RPC failed"  <font color="#990000">, error <font color="#990000">-&gt; message <font color="#990000">,                                                  TRUE <font color="#990000">);  <font color="#9A1900">/* Note that the whole call failed, not "just" the name  '' <font color="#9A1900">      registration (we deal with that below). This means that ''  <font color="#9A1900">      something bad probably has happened and there is not much we can  '' <font color="#9A1900">      do (hence program termination). */ ''   <font color="#FF0000">} '' <font color="#9A1900">/* Check the result code of the registration RPC. */ ''    <font color="#000000">g_print   <font color="#990000">( PROGNAME <font color="#FF0000">":main RequestName returned %d.  <font color="#CC33CC">\n  <font color="#FF0000">"  <font color="#990000">, result <font color="#990000">);  <font color="#0000FF">if  <font color="#990000">( result <font color="#990000"> !=  <font color="#993399">1  <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">handleError  <font color="#990000">(  <font color="#FF0000">"Failed to get the primary well-known name."  <font color="#990000">,                  <font color="#FF0000">"RequestName result != 1"  <font color="#990000">, TRUE <font color="#990000">); '' <font color="#9A1900">/* In this case we could also continue instead of terminating.   <font color="#9A1900">       We could retry the RPC later. Or "lurk" on the bus waiting for '' '' <font color="#9A1900">      someone to tell us what to do. If we would be publishing ''  <font color="#9A1900">      multiple services and/or interfaces, it even might make sense  '' <font color="#9A1900">      to continue with the rest anyway.   <font color="#9A1900">       In our simple program, we terminate. Not much left to do for ''  <font color="#9A1900">      this poor program if the clients will not be able to find the  '' <font color="#9A1900">      Value object using the well-known name. */ ''   <font color="#FF0000">} </tt>

The dbus_g_proxy_call function is used to do synchronous method calls in GLib/D-Bus wrappers, and in this case, it will be used to run the two argument RequestName method call. The method returns one value (and uint32), which encodes the result of the well-known name registration.

One needs to be careful with the order and correctness of the parameters to the function call, as it is easy to get something wrong, and the C compiler cannot really check for parameter type validity here.

After the successful name registration, it is finally time to create an instance of the ValueObject and publish it on the D-Bus: glib-dbus-sync/server.c

<tt>  <font color="#000000">g_print   <font color="#990000">( PROGNAME <font color="#FF0000">":main Creating one Value object.  <font color="#CC33CC">\n  <font color="#FF0000">"  <font color="#990000">);  <font color="#9A1900">/* The NULL at the end means that we have stopped listing the   <font color="#9A1900">    property names and their values that would have been used to  '' <font color="#9A1900">    set the properties to initial values. Our simple Value ''  <font color="#9A1900">    implementation does not support GObject properties, and also   <font color="#9A1900">    does not inherit anything interesting from GObject directly, so  '' <font color="#9A1900">    there are no properties to set. For more examples on properties ''  <font color="#9A1900">    see the first GTK+ example programs from the maemo Application  '' <font color="#9A1900">    Development material.   <font color="#9A1900">     NOTE: You need to keep at least one reference to the published ''  <font color="#9A1900">          object at all times, unless you want it to disappear from   <font color="#9A1900">          the D-Bus (implied by API reference for    <font color="#9A1900">           dbus_g_connection_register_g_object. */     valueObj <font color="#990000"> =   <font color="#000000">g_object_new   <font color="#990000">( VALUE_TYPE_OBJECT <font color="#990000">, NULL <font color="#990000">);     <font color="#0000FF">if   <font color="#990000">( valueObj <font color="#990000"> == NULL <font color="#990000">)  <font color="#FF0000">{       <font color="#000000">handleError   <font color="#990000">(  <font color="#FF0000">"Failed to create one Value instance." <font color="#990000">, <font color="#FF0000">"Unknown(OOM?)" <font color="#990000">, TRUE <font color="#990000">);    <font color="#FF0000">}     <font color="#000000">g_print   <font color="#990000">( PROGNAME <font color="#FF0000">":main Registering it on the D-Bus.  <font color="#CC33CC">\n  <font color="#FF0000">"  <font color="#990000">);     <font color="#9A1900">/* The function does not return any status, so can not check for    <font color="#9A1900">     errors here. */      <font color="#000000">dbus_g_connection_register_g_object   <font color="#990000">( bus <font color="#990000">, VALUE_SERVICE_OBJECT_PATH <font color="#990000">,  <font color="#000000">G_OBJECT  <font color="#990000">( valueObj <font color="#990000">));     <font color="#000000">g_print   <font color="#990000">( PROGNAME <font color="#FF0000">":main Ready to serve requests (daemonizing).  <font color="#CC33CC">\n  <font color="#FF0000">"  <font color="#990000">);     <font color="#9A1900">/*... Listing cut for brevity ...*/   <font color="#FF0000">}  </tt>

And after this, the main will enter into the main loop, and will serve client requests coming over the D-Bus, until the server is terminated. N.B. All the callback registration is performed automatically by the GLib/D-Bus wrappers on object publication, so there is no need to worry about them.

Implementing the dependencies and rules for the server and the generated stub code will give this snippet: glib-dbus-sync/Makefile

<tt>server <font color="#990000"> : server <font color="#990000">. o        <font color="#009900">$(CC)  <font color="#009900">$^ -o <font color="#009900">$@  <font color="#009900">$(LDFLAGS) '' <font color="#9A1900"> # ... Listing cut for brevity ...   <font color="#9A1900"> # The server and client depend on the respective implementation source ''  <font color="#9A1900"> # files, but also on the common interface as well as the generated  '' <font color="#9A1900"> # stub interfaces. '' server <font color="#990000">. o <font color="#990000"> : server <font color="#990000">. c common-defs <font color="#990000">. h value-server-stub <font color="#990000">. h        <font color="#009900">$(CC)  <font color="#009900">$(CFLAGS) -DPROGNAME <font color="#990000"> = \" <font color="#009900">$( basename <font color="#009900">$@  <font color="#990000">) \" -c <font color="#009900">$&lt; -o <font color="#009900">$@ </tt>

When implementing makefiles that separate compilation from linking, it is not possible to pass the target name (automatic variable $@) directly as the PROGNAME-define (since that would expand into server.o, and would look slightly silly when all the messages were prefixed with the name). Instead, a GNU make function (basename) is used to strip any prefixes and suffixes out of the parameter. This way, the PROGNAME will be set to server.

The next step is to build the server and start it:

[sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; make server dbus-binding-tool --prefix=value_object --mode=glib-server \ value-dbus-interface.xml &gt; value-server-stub.h cc -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -Wall -DG_DISABLE_DEPRECATED -DNO_DAEMON -DPROGNAME=\"server\" -c server.c -o server.o cc server.o -o server -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lglib-2.0 [sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; run-standalone.sh ./server server:main Connecting to the Session D-Bus. server:main Registering the well-known name (org.maemo.Platdev_ex) server:main RequestName returned 1. server:main Creating one Value object. server:value_object_class_init: Called server:value_object_class_init: Binding to GLib/D-Bus server:value_object_class_init: Done server:value_object_init: Called server:main Registering it on the D-Bus. server:main Ready to serve requests (daemonizing). server: Not daemonizing (built with NO_DAEMON-build define)

After this, dbus-send is used to test out the implementation details from the server. This is done in the same session (for simplicity) by first suspending the server with Ctrl+z, and then continuing running it with the bg shell built-in command. This is done so that it will be easier to see the reaction of the server to each dbus-send command.

The first step here is to test the getvalue1 and setvalue1 methods:

[Ctrl+z] [1]+ Stopped                 run-standalone.sh ./server [sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; bg [1]+ run-standalone.sh ./server &amp; [sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; run-standalone.sh dbus-send \ --type=method_call --print-reply --dest=org.maemo.Platdev_ex \ /GlobalValue org.maemo.Value.getvalue1 server:value_object_getvalue1: Called (internal value1 is 0) method return sender=:1.15 -&gt; dest=:1.20 int32 0 [sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; run-standalone.sh dbus-send \ --type=method_call --print-reply --dest=org.maemo.Platdev_ex \ /GlobalValue org.maemo.Value.setvalue1 int32:5 server:value_object_setvalue1: Called (valueIn=5) method return sender=:1.15 -&gt; dest=:1.21 [sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; run-standalone.sh dbus-send \ --type=method_call --print-reply --dest=org.maemo.Platdev_ex \ /GlobalValue org.maemo.Value.getvalue1 server:value_object_getvalue1: Called (internal value1 is 5) method return sender=:1.15 -&gt; dest=:1.22 int32 5

The next step is to test the double state variable with getvalue2 and setvalue2 methods:

[sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; run-standalone.sh dbus-send \ --type=method_call --print-reply --dest=org.maemo.Platdev_ex \ /GlobalValue org.maemo.Value.getvalue2 server:value_object_getvalue2: Called (internal value2 is 0.000) method return sender=:1.15 -&gt; dest=:1.23 double 0 [sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; run-standalone.sh dbus-send \ --type=method_call --print-reply --dest=org.maemo.Platdev_ex \ /GlobalValue org.maemo.Value.setvalue2 double:42.0 server:value_object_setvalue2: Called (valueIn=42.000) method return sender=:1.15 -&gt; dest=:1.24 [sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; run-standalone.sh dbus-send \ --type=method_call --print-reply --dest=org.maemo.Platdev_ex \ /GlobalValue org.maemo.Value.getvalue2 server:value_object_getvalue2: Called (internal value2 is 42.000) method return sender=:1.15 -&gt; dest=:1.25 double 42

This results in a fully functional D-Bus service implementation, albeit a very simple one.

The next step is to utilize the service from a client.

Using GLib/D-Bus Wrapper from Client
By using the generated client stub file, it is now possible to write the client that will invoke the methods on the Value object. The D-Bus method calls could also be performed "manually" (either with GLib/D-Bus functions, or even by using libdbus directly, but the latter is discouraged).

The dbus-bindings-tool (when run with the =glib-client parameter) will generate functions for each of the interface methods, and the functions will handle data marshaling operations internally.

Two generated stub functions are presented below, and they will be used shortly: glib-dbus-sync/value-client-stub.h

<tt> '' <font color="#9A1900">/* Generated by dbus-binding-tool; do not edit! */     <font color="#9A1900">/*... Listing cut for brevity ...*/ ''  <font color="#0000FF">static   <font color="#000080"> #ifdef  G_HAVE_INLINE inline  <font color="#000080"> #endif  gboolean  <font color="#000000">org_maemo_Value_getvalue1  <font color="#990000">( DBusGProxy <font color="#990000"> * proxy <font color="#990000">, gint <font color="#990000"> * OUT_cur_value <font color="#990000">,                                                GError <font color="#990000"> ** error <font color="#990000">) <font color="#FF0000">{  <font color="#0000FF">return   <font color="#000000">dbus_g_proxy_call   <font color="#990000">( proxy <font color="#990000">,  <font color="#FF0000">"getvalue1"  <font color="#990000">, error <font color="#990000">, G_TYPE_INVALID <font color="#990000">,                              G_TYPE_INT <font color="#990000">, OUT_cur_value <font color="#990000">, G_TYPE_INVALID <font color="#990000">); <font color="#FF0000">} '' <font color="#9A1900">/*... Listing cut for brevity ...*/ ''  <font color="#0000FF">static   <font color="#000080"> #ifdef  G_HAVE_INLINE inline  <font color="#000080"> #endif  gboolean  <font color="#000000">org_maemo_Value_setvalue1  <font color="#990000">( DBusGProxy <font color="#990000"> * proxy <font color="#990000">,   <font color="#0000FF">const  gint IN_new_value <font color="#990000">,                                                GError <font color="#990000"> ** error <font color="#990000">) <font color="#FF0000">{  <font color="#0000FF">return   <font color="#000000">dbus_g_proxy_call   <font color="#990000">( proxy <font color="#990000">,  <font color="#FF0000">"setvalue1"  <font color="#990000">, error <font color="#990000">, G_TYPE_INT <font color="#990000">,                              IN_new_value <font color="#990000">, G_TYPE_INVALID <font color="#990000">,                              G_TYPE_INVALID <font color="#990000">); <font color="#FF0000">} </tt>

The two functions presented above are both blocking, which means that they will wait for the result to arrive over the D-Bus, and only then return to the caller. The generated stub code also includes asynchronous functions (their names end with _async), but their usage will be covered later.

For now, it is important to notice how the prototypes of the functions are named, and what are the parameters that they expect to be passed to them.

The org_maemo_Value prefix is taken from the interface XML file, from the name attribute of the interface element. All dots will be converted into underscores (since C reserves the dot character for other uses), but otherwise the name will be preserved (barring dashes in the name).

The rest of the function name will be the method name for each method defined in the interface XML file.

The first parameter for all the generated stub functions will always be a pointer to a DBusProxy object, which will be necessary to use with the GLib/D-Bus wrapper functions. After the proxy, a list of method parameters is passed. The binding tool will prefix the parameter names with either IN_ or OUT_ depending on the "direction" of the parameter. Rest of the parameter name is taken from the name attributed of the arg element for the method, or if not given, will be automatically generated as arg0, arg1, etc. Input parameters will be passed as values (unless they are complex or strings, in which case they will be passed as pointers). Output parameters are always passed as pointers.

The functions will always return a gboolean, indicating failure or success, and if they fail, they will also create and set the error pointer to an GError -object which can then be checked for the reason for the error (unless the caller passed a NULL pointer for error, in which case the error object will not be created). glib-dbus-sync/client.c

<tt>  <font color="#000080"> #include  <font color="#FF0000">&lt;glib.h&gt;  <font color="#000080"> #include  <font color="#FF0000">&lt;dbus/dbus-glib.h&gt;  <font color="#000080"> #include  <font color="#FF0000">&lt;stdlib.h&gt;   <font color="#9A1900">/* exit, EXIT_FAILURE */   <font color="#000080"> #include  <font color="#FF0000">&lt;string.h&gt;   <font color="#9A1900">/* strcmp */  '' <font color="#9A1900">/* Pull the common symbolic defines. */   <font color="#000080"> #include   <font color="#FF0000">"common-defs.h"   <font color="#9A1900">/* Pull in the client stubs that were generated with ''  <font color="#9A1900">  dbus-binding-tool */   <font color="#000080"> #include  <font color="#FF0000">"value-client-stub.h" </tt>

This will allow the client code to use the stub code directly as follows: glib-dbus-sync/client.c

<tt>  <font color="#9A1900">/**   <font color="#9A1900"> * This function will be called repeatedly from within the mainloop  '' <font color="#9A1900"> * timer launch code.   <font color="#9A1900"> * ''  <font color="#9A1900"> * The function will start with two statically initialized variables   <font color="#9A1900"> * (int and double) which will be incremented after each time this   <font color="#9A1900"> * function runs and will use the setvalue* remote methods to set the  '' <font color="#9A1900"> * new values. If the set methods fail, program is not aborted, but an '' '' <font color="#9A1900"> * message will be issued to the user describing the error.   <font color="#9A1900"> */ ''  <font color="#0000FF">static  gboolean  <font color="#000000">timerCallback  <font color="#990000">( DBusGProxy <font color="#990000"> * remoteobj <font color="#990000">)  <font color="#FF0000">{ '' <font color="#9A1900">/* Local values that we'll start updating to the remote object. */ ''    <font color="#0000FF">static  gint localValue1 <font color="#990000"> =  <font color="#990000">-  <font color="#993399">80  <font color="#990000"> ;  <font color="#0000FF">static  gdouble localValue2 <font color="#990000"> = <font color="#990000">-  <font color="#993399">120.0  <font color="#990000"> ; GError <font color="#990000"> * error <font color="#990000"> = NULL <font color="#990000"> ; '' <font color="#9A1900">/* Set the first value. */ ''    <font color="#000000">org_maemo_Value_setvalue1   <font color="#990000">( remoteobj <font color="#990000">, localValue1 <font color="#990000">,  <font color="#990000">&amp; error <font color="#990000">);  <font color="#0000FF">if  <font color="#990000">( error <font color="#990000"> != NULL <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">handleError  <font color="#990000">(  <font color="#FF0000">"Failed to set value1"  <font color="#990000">, error <font color="#990000">-&gt; message <font color="#990000">, FALSE <font color="#990000">); <font color="#FF0000">}  <font color="#0000FF">else   <font color="#FF0000">{  <font color="#000000">g_print  <font color="#990000">( PROGNAME <font color="#FF0000">":timerCallback Set value1 to %d  <font color="#CC33CC">\n  <font color="#FF0000">"  <font color="#990000">, localValue1 <font color="#990000">); <font color="#FF0000">}  <font color="#9A1900">/* If there was an error with the first, release the error, and  '' <font color="#9A1900">    don't attempt the second time. Also, don't add to the local '' '' <font color="#9A1900">    values. We assume that errors from the first set are caused by ''  <font color="#9A1900">    server going off the D-Bus, but are hopeful that it will come  '' <font color="#9A1900">    back, and hence keep trying (returning TRUE). */ ''    <font color="#0000FF">if   <font color="#990000">( error <font color="#990000"> != NULL <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">g_clear_error  <font color="#990000">(&amp; error <font color="#990000">);  <font color="#0000FF">return  TRUE <font color="#990000"> ; <font color="#FF0000">} '' <font color="#9A1900">/* Now try to set the second value as well. */ ''    <font color="#000000">org_maemo_Value_setvalue2   <font color="#990000">( remoteobj <font color="#990000">, localValue2 <font color="#990000">,  <font color="#990000">&amp; error <font color="#990000">);  <font color="#0000FF">if  <font color="#990000">( error <font color="#990000"> != NULL <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">handleError  <font color="#990000">(  <font color="#FF0000">"Failed to set value2"  <font color="#990000">, error <font color="#990000">-&gt; message <font color="#990000">, FALSE <font color="#990000">);  <font color="#000000">g_clear_error  <font color="#990000">(&amp; error <font color="#990000">);  '' <font color="#9A1900">/* Or g_error_free in this case. */ ''   <font color="#FF0000">}   <font color="#0000FF">else   <font color="#FF0000">{  <font color="#000000">g_print  <font color="#990000">( PROGNAME <font color="#FF0000">":timerCallback Set value2 to %.3lf  <font color="#CC33CC">\n  <font color="#FF0000">"  <font color="#990000">, localValue2 <font color="#990000">); <font color="#FF0000">} '' <font color="#9A1900">/* Step the local values forward. */ ''   localValue1 <font color="#990000">+=  <font color="#993399">10  <font color="#990000"> ; localValue2 <font color="#990000">+= <font color="#993399">10.0  <font color="#990000"> ;  <font color="#9A1900">/* Tell the timer launcher that we want to remain on the timer  '' <font color="#9A1900">    call list in the future as well. Returning FALSE here would '' '' <font color="#9A1900">    stop the launch of this timer callback. */ ''    <font color="#0000FF">return  TRUE <font color="#990000"> ; <font color="#FF0000">} </tt>

What is left is connecting to the correct D-Bus, creating a GProxy object which will be done in the test program: glib-dbus-sync/client.c

<tt>  <font color="#9A1900">/**  '' <font color="#9A1900"> * The test program itself.   <font color="#9A1900"> * ''  <font color="#9A1900"> * 1) Setup GType/GSignal   <font color="#9A1900"> * 2) Create GMainLoop object   <font color="#9A1900"> * 3) Connect to the Session D-Bus   <font color="#9A1900"> * 4) Create a proxy GObject for the remote Value object   <font color="#9A1900"> * 5) Start a timer that will launch timerCallback once per second.   <font color="#9A1900"> * 6) Run main-loop (forever)   <font color="#9A1900"> */  <font color="#009900">int  <font color="#000000">main   <font color="#990000">(  <font color="#009900">int argc <font color="#990000">,  <font color="#009900">char  <font color="#990000"> ** argv <font color="#990000">)  <font color="#FF0000">{ '' <font color="#9A1900">/* The D-Bus connection object. Provided by GLib/D-Bus wrappers. */ ''   DBusGConnection <font color="#990000"> * bus <font color="#990000"> ;  <font color="#9A1900">/* This will represent the Value object locally (acting as a proxy   <font color="#9A1900">     for all method calls and signal delivery. */     DBusGProxy <font color="#990000"> * remoteValue <font color="#990000"> ;     <font color="#9A1900">/* This will refer to the GMainLoop object */     GMainLoop <font color="#990000"> * mainloop <font color="#990000"> ;    GError <font color="#990000"> * error <font color="#990000"> = NULL <font color="#990000"> ;     <font color="#9A1900">/* Initialize the GType/GObject system. */      <font color="#000000">g_type_init   <font color="#990000">;     <font color="#9A1900">/* Create a new GMainLoop with default context (NULL) and initial    <font color="#9A1900">     state of "not running" (FALSE). */     mainloop <font color="#990000"> =   <font color="#000000">g_main_loop_new   <font color="#990000">( NULL <font color="#990000">, FALSE <font color="#990000">); '' <font color="#9A1900">/* Failure to create the main loop is fatal (for us). */ ''    <font color="#0000FF">if   <font color="#990000">( mainloop <font color="#990000"> == NULL <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">handleError  <font color="#990000">(  <font color="#FF0000">"Failed to create the mainloop"  <font color="#990000">,  <font color="#FF0000">"Unknown (OOM?)"  <font color="#990000">,                  TRUE <font color="#990000">); <font color="#FF0000">}  <font color="#000000">g_print  <font color="#990000">( PROGNAME <font color="#FF0000">":main Connecting to Session D-Bus.  <font color="#CC33CC">\n  <font color="#FF0000">"  <font color="#990000">); bus <font color="#990000"> =  <font color="#000000">dbus_g_bus_get   <font color="#990000">( DBUS_BUS_SESSION <font color="#990000">,  <font color="#990000">&amp; error <font color="#990000">);  <font color="#0000FF">if  <font color="#990000">( error <font color="#990000"> != NULL <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">handleError  <font color="#990000">(  <font color="#FF0000">"Couldn't connect to the Session bus"  <font color="#990000">, error <font color="#990000">-&gt; message <font color="#990000">,                  TRUE <font color="#990000">);  <font color="#9A1900">/* Normally you'd have to also g_error_free the error object   <font color="#9A1900">      but since the program will terminate within handleError,  '' <font color="#9A1900">      it is not necessary here. */ ''   <font color="#FF0000">}  <font color="#000000">g_print  <font color="#990000">( PROGNAME <font color="#FF0000">":main Creating a GLib proxy object for Value.  <font color="#CC33CC">\n  <font color="#FF0000">"  <font color="#990000">);  <font color="#9A1900">/* Create the proxy object that we'll be using to access the object  '' <font color="#9A1900">    on the server. If you would use dbus_g_proxy_for_name_owner, ''  <font color="#9A1900">    you would be also notified when the server that implements the  '' <font color="#9A1900">    object is removed (or rather, the interface is removed). Since ''  <font color="#9A1900">    we don't care who actually implements the interface, we'll use the  '' <font color="#9A1900">    more common function. See the API documentation at ''  <font color="#9A1900">        <font color="#0000FF">http://maemo.org/api_refs/4.0/dbus/    '' <font color="#9A1900"> for more details. */ ''   remoteValue <font color="#990000"> =  <font color="#000000">dbus_g_proxy_new_for_name  <font color="#990000">( bus <font color="#990000">,                                VALUE_SERVICE_NAME <font color="#990000">,   <font color="#9A1900">/* name */                                 VALUE_SERVICE_OBJECT_PATH <font color="#990000">,   <font color="#9A1900">/* obj path */                                 VALUE_SERVICE_INTERFACE  <font color="#9A1900">/* interface */   <font color="#990000">);  <font color="#0000FF">if  <font color="#990000">( remoteValue <font color="#990000"> == NULL <font color="#990000">)  <font color="#FF0000">{  <font color="#000000">handleError  <font color="#990000">(  <font color="#FF0000">"Couldn't create the proxy object"  <font color="#990000">,                  <font color="#FF0000">"Unknown(dbus_g_proxy_new_for_name)"  <font color="#990000">, TRUE <font color="#990000">); <font color="#FF0000">}  <font color="#000000">g_print  <font color="#990000">( PROGNAME <font color="#FF0000">":main Starting main loop (first timer in 1s).  <font color="#CC33CC">\n  <font color="#FF0000">"  <font color="#990000">); '' <font color="#9A1900">/* Register a timer callback that will do RPC sets on the values.   <font color="#9A1900">     The userdata pointer is used to pass the proxy object to the '' '' <font color="#9A1900">    callback so that it can launch modifications to the object. */ ''    <font color="#000000">g_timeout_add   <font color="#990000">(  <font color="#993399">1000  <font color="#990000">,  <font color="#990000">( GSourceFunc <font color="#990000">) timerCallback <font color="#990000">, remoteValue <font color="#990000">); '' <font color="#9A1900">/* Run the program. */ ''    <font color="#000000">g_main_loop_run   <font color="#990000">( mainloop <font color="#990000">);  <font color="#9A1900">/* Since the main loop is not stopped (by this code), we shouldn't  '' <font color="#9A1900">    ever get here. The program might abort for other reasons. */     <font color="#9A1900">/* If it does, return failure as exit code. */ ''    <font color="#0000FF">return  EXIT_FAILURE <font color="#990000"> ; <font color="#FF0000">} </tt>

Integrating the client into the Makefile is done the same way as was did for the server before: glib-dbus-sync/Makefile

<tt>client <font color="#990000"> : client <font color="#990000">. o        <font color="#009900">$(CC)  <font color="#009900">$^ -o <font color="#009900">$@  <font color="#009900">$(LDFLAGS) '' <font color="#9A1900"> # ... Listing cut for brevity ... '' client <font color="#990000">. o <font color="#990000"> : client <font color="#990000">. c common-defs <font color="#990000">. h value-client-stub <font color="#990000">. h        <font color="#009900">$(CC)  <font color="#009900">$(CFLAGS) -DPROGNAME <font color="#990000"> = \" <font color="#009900">$( basename <font color="#009900">$@  <font color="#990000">) \" -c <font color="#009900">$&lt; -o <font color="#009900">$@ </tt>

After building the client, will be started, and let it execute in the same terminal session where the server is still running:

[sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; make client dbus-binding-tool --prefix=value_object --mode=glib-client \ value-dbus-interface.xml &gt; value-client-stub.h cc -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include \ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -Wall \ -DG_DISABLE_DEPRECATED -DNO_DAEMON -DPROGNAME=\"client\" \ -c client.c -o client.o cc client.o -o client -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lglib-2.0 [sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; run-standalone.sh ./client client:main Connecting to Session D-Bus. client:main Creating a GLib proxy object for Value. client:main Starting main loop (first timer in 1s). server:value_object_setvalue1: Called (valueIn=-80) client:timerCallback Set value1 to -80 server:value_object_setvalue2: Called (valueIn=-120.000) client:timerCallback Set value2 to -120.000 server:value_object_setvalue1: Called (valueIn=-70) client:timerCallback Set value1 to -70 server:value_object_setvalue2: Called (valueIn=-110.000) client:timerCallback Set value2 to -110.000 server:value_object_setvalue1: Called (valueIn=-60) client:timerCallback Set value1 to -60 ... [Ctrl+c] [sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; fg run-standalone.sh ./server [Ctrl+c]

Since the client will normally run forever, it will now be terminated, and then the server will be moved to the foreground, so that it can also be terminated. This concludes the first GLib/D-Bus example, but for more information about the GLib D-Bus wrappers, please consult D-BUS GLib Bindings Documentation /node19.html.

D-Bus Introspection
D-Bus supports a mechanism by which programs can interrogate the bus for existing well-known names, and then get the interfaces implemented by the objects available behind the well-known names. This mechanism is called introspection in D-Bus terminology.

The main goal of supporting introspection in D-Bus is allowing dynamic bindings to be made with high-level programming languages. This way, the language wrappers for D-Bus can be more intelligent automatically (assuming they utilize the introspection interface). The GLib-wrappers do not use the introspection interface.

Introspection is achieved with three D-Bus methods: ListNames, GetNameOwner and Introspect. The destination object must support the introspection interface in order to provide this information. If the dbus-bindings-tool is used, and the GObject is registered correctly, the service will automatically support introspection.

D-Bus (at this moment) does not come with introspection utilities, but some are available from other sources. One simple program is the "DBus Inspector" that is written in Python, and uses the Python D-Bus bindings and GTK+. If planning to write one's own tool, it is necessary to prepare to parse XML data, since that is the format of results that the Introspect method returns.

<font size="-1">Using DBUS Inspector on GlobalValue on a desktop system. Note that the version of GlobalValue used here also implements signals, which will be covered next

Introspection can also be useful, when trying to find out what are the different interfaces and methods available for use on a system. It just has to be remembered that not all D-Bus services actually implement the introspection interface. Their well-known names can still be received, but their interface descriptions will come up empty when using Introspect.