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

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

Warning: This page is 51 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

==Introduction to GObjects ==

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

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

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

The per-class constructor and the per-object constructor must be implemented. Both of these are quite short for the first version of the implementation.

== D-Bus Interface Definition Using XML ==

Because the primary objective here is to make the object available over D-Bus, the example starts by covering one of the easiest way of achieving this: the dbus-bindings-tool. The tool generates a lot of the bindings code for both the client and server side. As input the 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 is copied into the generated stub code automatically by the tool). The first method is setvalue1, which gets one argument, new_value, which is an 32-bit signed integer: glib-dbus-sync/value-dbus-interface.xml

Define each argument explicitly with the arg element. The type attribute is required because it defines the data type for the argument. Arguments are sometimes called parameters when they are 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 is out. If a method call does not return any value (returns void), no argument with the direction out needs to be specified.

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):

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

From the above list, it can be seen that setvalue1 accepts one 32-bit signed integer argument (<code>new_value</code>). The name of the argument affects the generated stub code prototypes (not the implementation), but is quite useful for documentation, and also for D-Bus introspection.

The next step is the interface specification of another method: <code>getvalue1</code>, which returns 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

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

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

Multiple interfaces can be implemented in the same object, and if this is the case, the multiple interface elements are listed within the node element. The node element is the "top-level" element. In this case, only one explicit interface is implemented (the binding tools 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

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

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, because DTD validation can only check for syntax and structure, but not for 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

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

<pre>
[sbox-DIABLO_X86: ~/glib-dbus-sync] > make checkxml
value-dbus-interface.xml checks out ok
</pre>

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 (<code>invalidElement</code>), and by removing one starting tag (method).

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

^
make: *** [checkxml] Error 1
</pre>

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, it is not always  the best solution.

==Generating Automatic Stub Code ==

The following step is to generate the "glue" code that implements the mapping from GLib into D-Bus. The generated code is used later on, but it is useful to see at this point what the dbus-binding-tool program generates.

Expand the '''Makefile''' 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

<source lang="c">
# Define a list of generated files so that they can be cleaned as well
cleanfiles := value-client-stub.h \
              value-server-stub.h

# ... Listing cut for brevity ...

# If the interface XML changes, the respective stub interfaces are
# automatically regenerated. Normally this also means that your
# builds fail after this because you are missing implementation
# code.
value-server-stub.h: $(interface_xml)
        dbus-binding-tool --prefix=value_object --mode=glib-server \
          $< > $@

value-client-stub.h: $(interface_xml)
        dbus-binding-tool --prefix=value_object --mode=glib-client \
          $< > $@

# ... Listing cut for brevity ...

clean:
        $(RM) $(targets) $(cleanfiles) *.o
</source>

Pass two parameters for the <code>dbus-binding-tool</code> program. Use the <code>--prefix</code> parameter to tell which text is prefixed to all generated structure and function names. This helps to avoid namespace collisions when pulling the generated glue files back into the programs. The value_object is used because it seems like a logical prefix for the project. 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 selects what kind of output the tool generates. At the moment, the tool only supports generating GLib/D-Bus bindings, but this might change in the future. Furthermore, select which "side" of the D-Bus the bindings are 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 results in the following two header files:

<pre>
 [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
</pre>

Check what the tool produced, starting with the server stub file: glib-dbus-sync/value-server-stub.h

<source lang="c">
/* Generated by dbus-binding-tool; do not edit! */

/*... Listing cut for brevity ...*/

#include <dbus/dbus-glib.h>
static const DBusGMethodInfo dbus_glib_value_object_methods[] = {
  { (GCallback) value_object_getvalue1,
    dbus_glib_marshal_value_object_BOOLEAN__POINTER_POINTER, 0 },
  { (GCallback) value_object_getvalue2,
    dbus_glib_marshal_value_object_BOOLEAN__POINTER_POINTER, 47 },
  { (GCallback) value_object_setvalue1,
    dbus_glib_marshal_value_object_BOOLEAN__INT_POINTER, 94 },
  { (GCallback) value_object_setvalue2,
    dbus_glib_marshal_value_object_BOOLEAN__DOUBLE_POINTER, 137 },
};

const DBusGObjectInfo dbus_glib_value_object_object_info = {
  0,
  dbus_glib_value_object_methods,
  4,
"org.maemo.Value\0getvalue1\0S\0cur_value\0O\0F\0N\0i\0\0"
"org.maemo.Value\0getvalue2\0S\0cur_value\0O\0F\0N\0d\0\0"
"org.maemo.Value\0setvalue1\0S\0new_value\0I\0i\0\0"
"org.maemo.Value\0setvalue2\0S\0new_value\0I\0d\0\0\0",
"\0",
"\0"
};
</source>

The interest here lies in the method table, mainly because it lists the names of the functions that must be implemented: <code>value_object_getvalue1</code>, <code>0_object_getvalue2</code>, <code>value_object_setvalue1</code> and <code>value_object_setvalue2</code>. 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 <code>dbus_glib_marshal_*</code>). 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, to make two different parameter passing conventions compatible. It is a common feature found in almost all RPC mechanisms. Because GLib has its own type system and a D-Bus of its own, it is 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 <code>_object_info</code> structure. The structure is 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 zeros) 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. The structure is also an important part of the D-Bus introspection mechanism.

As the snippet says at the very first line, do not edit it 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 <code>dbus-binding-tool</code>. Needless to say, this makes maintenance of the interface much more difficult and is not really recommended. The generated stub code is not edited in this material.

The example continues next 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 (<code>value1</code> and <code>value2</code>), with which the rest of this example is concerned: glib-dbus-sync/server.c

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

The convenience macros are defined in a way expected for all <code>GType</code>s. The <code>G_TYPE_</code> macros are defined in <code>GType</code> and include the magic by which the object implementation does not need to know much about the internal specifics of <code>GType</code>. The <code>GType</code> macros are described in the [http://maemo.org/api_refs/5.0/beta/gobject/ GObject API reference for GType].

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

<source lang="c">
/* Forward declaration of the function that returns the GType of
   the Value implementation. Not used in this program because we only
   need to push this over the D-Bus. */
GType value_object_get_type(void);

/* Macro for the above. It is common to define macros using the
   naming convention (seen below) for all GType implementations,
   and that is why we are going to do that here as well. */
#define VALUE_TYPE_OBJECT (value_object_get_type())

#define VALUE_OBJECT(object) \
        (G_TYPE_CHECK_INSTANCE_CAST((object), \
         VALUE_TYPE_OBJECT, ValueObject))
#define VALUE_OBJECT_CLASS(klass) \
        (G_TYPE_CHECK_CLASS_CAST((klass), \
         VALUE_TYPE_OBJECT, ValueObjectClass))
#define VALUE_IS_OBJECT(object) \
        (G_TYPE_CHECK_INSTANCE_TYPE((object), \
         VALUE_TYPE_OBJECT))
#define VALUE_IS_OBJECT_CLASS(klass) \
        (G_TYPE_CHECK_CLASS_TYPE((klass), \
         VALUE_TYPE_OBJECT))
#define VALUE_OBJECT_GET_CLASS(obj) \
        (G_TYPE_INSTANCE_GET_CLASS((obj), \
         VALUE_TYPE_OBJECT, ValueObjectClass))

/* Utility macro to define the value_object GType structure. */
G_DEFINE_TYPE(ValueObject, value_object, G_TYPE_OBJECT)
</source>

The <code>dbus_g_object_type_install_info</code> function takes a pointer to the structure describing the D-Bus integration (<code>dbus_glib_value_object_object_info</code>), which is generated by <code>dbus-bindings-tool</code>. This function creates all the necessary runtime information for the <code>GType</code>, so the details can be left alone. It also attaches the introspection data to the <code>GType</code>, so that D-Bus introspection may return information on the interface that the object implements.

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

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

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

Do not return the values in the conventional C way (by using return someVal), but instead the return values are written using the given pointers. The return value of the method is always a gboolean, signifying either success or failure. If failure (<code>FALSE</code>) is returned, create and setup a <code>GError</code> object, and store its address to the error location.

== Publishing GType on D-Bus ==

Once the implementation is complete, an instance of the class must be published onto the D-Bus. This is done inside the main of the server example and involves performing a D-Bus method call on the bus.

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

<source lang="c">
/* Well-known name for this service. */
#define VALUE_SERVICE_NAME        "org.maemo.Platdev_ex"
/* Object path to the provided object. */
#define VALUE_SERVICE_OBJECT_PATH "/GlobalValue"
/* And we are interested in using it through this interface.
   This must match the entry in the interface definition XML. */
#define VALUE_SERVICE_INTERFACE   "org.maemo.Value"
</source>

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

Before using any of the <code>GType</code> functions, the runtime system must be initialized by calling <code>g_type_init</code>. This creates the built-in types and sets up all the machinery necessary for creating custom types. When using GTK+, the function is called automatically if GTK+ is initialized. Because this example only uses GLib, the function must be called manually.

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

<source lang="c">
/* Pull symbolic constants that are shared (in this example) between
   the client and the server. */
#include "common-defs.h"

/*... Listing cut for brevity ...*/

int main(int argc, char** argv) {

/*... Listing cut for brevity ...*/

/* Initialize the GType/GObject system. */
  g_type_init();

/*... Listing cut for brevity ...*/

g_print(PROGNAME ":main Connecting to the Session D-Bus.\n");
  bus = dbus_g_bus_get(DBUS_BUS_SESSION, &error);
  if (error != NULL) {
    /* Print error and terminate. */
    handleError("Could not connect to session bus", error->message, TRUE);
  }
</source>

For prospective clients to find the object on the session bus, attach the server to a well-known name by using the <code>RequestName</code> method call on the D-Bus server (over D-Bus). To target the server, create a GLib/D-Bus proxy object first: glib-dbus-sync/server.c

<source lang="c">
  g_print(PROGNAME ":main Registering the well-known name (%s)\n",
          VALUE_SERVICE_NAME);

/* In order to register a well-known name, we need to use the
     "RequestMethod" of the /org/freedesktop/DBus interface. Each
     bus provides an object that implements this interface.

In order to do the call, we need a proxy object first.
     DBUS_SERVICE_DBUS = "org.freedesktop.DBus"
     DBUS_PATH_DBUS = "/org/freedesktop/DBus"
     DBUS_INTERFACE_DBUS = "org.freedesktop.DBus" */
  busProxy = dbus_g_proxy_new_for_name(bus,
                                       DBUS_SERVICE_DBUS,
                                       DBUS_PATH_DBUS,
                                       DBUS_INTERFACE_DBUS);
  if (busProxy == NULL) {
    handleError("Failed to get a proxy for D-Bus",
                "Unknown(dbus_g_proxy_new_for_name)", TRUE);
  }

/* Attempt to register the well-known name.
     The RPC call requires two parameters:
     - arg0: (D-Bus STRING): name to request
     - arg1: (D-Bus UINT32): flags for registration.
       (please see "org.freedesktop.DBus.RequestName" in
        http://dbus.freedesktop.org/doc/dbus-specification.html)
     Returns one uint32 giving the result of the RPC call.
     We are interested in 1 (we are now the primary owner of the name)
     or 4 (we were already the owner of the name, however in this
     application it does not make much sense).

The function returns FALSE if it sets the GError. */
  if (!dbus_g_proxy_call(busProxy,
                         /* Method name to call. */
                         "RequestName",
                         /* Where to store the GError. */
                         &error,
                         /* Parameter type of argument 0. Note that
                            because we are dealing with GLib/D-Bus
                            wrappers, you need to find a suitable
                            GType instead of using the "native" D-Bus
                            type codes. */
                         G_TYPE_STRING,
                         /* Data of argument 0. In our case, this is
                            the well-known name for our server
                            example ("org.maemo.Platdev_ex"). */
                         VALUE_SERVICE_NAME,
                         /* Parameter type of argument 1. */
                         G_TYPE_UINT,
                         /* Data of argument 0. This is the "flags"
                            argument of the "RequestName" method which
                            can be use to specify what the bus service
                            should do when the name already exists on
                            the bus. We go with defaults. */
                         0,
                         /* Input arguments are terminated with a
                            special GType marker. */
                         G_TYPE_INVALID,
                         /* Parameter type of return value 0.
                            For "RequestName" it is UINT32 so we pick
                            the GType that maps into UINT32 in the
                            wrappers. */
                         G_TYPE_UINT,
                         /* Data of return value 0. These are always
                            pointers to the locations where the
                            proxy can copy the results. */
                         &result,
                         /* Terminate list of return values. */
                         G_TYPE_INVALID)) {
    handleError("D-Bus.RequestName RPC failed", error->message,
                                                TRUE);
    /* Note that the whole call failed, not "just" the name
       registration (we deal with that below). This means that
       something bad probably has happened and there is not much we can
       do (hence program termination). */
  }
  /* Check the result code of the registration RPC. */
  g_print(PROGNAME ":main RequestName returned %d.\n", result);
  if (result != 1) {
    handleError("Failed to get the primary well-known name.",
                "RequestName result != 1", TRUE);
    /* In this case we could also continue instead of terminating.
       We could retry the RPC later. Or "lurk" on the bus waiting for
       someone to tell us what to do. If we were publishing
       multiple services and/or interfaces, it even might make sense
       to continue with the rest anyway.

In our simple program, we terminate. Not much left to do for
       this poor program if the clients are not able to find the
       Value object using the well-known name. */
  }
</source>

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

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, an instance of the <code>ValueObject</code> is created and published on the D-Bus: glib-dbus-sync/server.c

<source lang="c">
  g_print(PROGNAME ":main Creating one Value object.\n");
  /* The NULL at the end means that we have stopped listing the
     property names and their values that had been used to
     set the properties to initial values. Our simple Value
     implementation does not support GObject properties, and also
     does not inherit anything interesting from GObject directly, so
     there are no properties to set. For more examples on properties
     see the first GTK+ example programs from the maemo Application
     Development material.

NOTE: You need to keep at least one reference to the published
           object at all times, unless you want it to disappear from
           the D-Bus (implied by API reference for
           dbus_g_connection_register_g_object(). */
  valueObj = g_object_new(VALUE_TYPE_OBJECT, NULL);
  if (valueObj == NULL) {
    handleError("Failed to create one Value instance.",
                "Unknown(OOM?)", TRUE);
  }

g_print(PROGNAME ":main Registering it on the D-Bus.\n");
  /* The function does not return any status, so can not check for
     errors here. */
  dbus_g_connection_register_g_object(bus,
                                      VALUE_SERVICE_OBJECT_PATH,
                                      G_OBJECT(valueObj));

g_print(PROGNAME ":main Ready to serve requests (daemonizing).\n");

/*... Listing cut for brevity ...*/

}
</source>

After this, the main enters into the main loop, and serves client requests coming over the D-Bus, until the server is terminated.

All 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 gives this snippet: glib-dbus-sync/Makefile

<source lang="c">
server: server.o
        $(CC) $^ -o $@ $(LDFLAGS)

# ... Listing cut for brevity ...

# The server and client depend on the respective implementation source
# files, but also on the common interface as well as the generated
# stub interfaces.
server.o: server.c common-defs.h value-server-stub.h
        $(CC) $(CFLAGS) -DPROGNAME=\"$(basename $@)\" -c $< -o $@
</source>

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

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

<pre>
 [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)
</pre>

After this, use <code>dbus-send</code> 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 <code>bg</code> shell built-in command. This is done so that it is easier to see the reaction of the server to each dbus-send command.

The first step here is to test the <code>getvalue1</code> and <code>setvalue1</code> methods:

<pre>
[Ctrl+z]
[1]+  Stopped                 run-standalone.sh ./server
[sbox-DIABLO_X86: ~/glib-dbus-sync] > bg
[1]+ run-standalone.sh ./server &
[sbox-DIABLO_X86: ~/glib-dbus-sync] > 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 -> dest=:1.20
 int32 0
[sbox-DIABLO_X86: ~/glib-dbus-sync] > 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 -> dest=:1.21
[sbox-DIABLO_X86: ~/glib-dbus-sync] > 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 -> dest=:1.22
 int32 5
</pre>

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

<pre>
[sbox-DIABLO_X86: ~/glib-dbus-sync] > 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 -> dest=:1.23
 double 0
[sbox-DIABLO_X86: ~/glib-dbus-sync] > 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 -> dest=:1.24
[sbox-DIABLO_X86: ~/glib-dbus-sync] > 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 -> dest=:1.25
 double 42
</pre>

This results in a fully functional D-Bus service implementation, although 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, the client that invokes the methods on the Value object can now be written. The D-Bus method calls can also be performed "manually" (either with GLib/D-Bus functions, or even by using libdbus directly, but the latter is discouraged).

The <code>dbus-bindings-tool</code> (when run with the <code>--mode=glib-client</code> parameter) generates functions for each of the interface methods, and the functions handle data marshaling operations internally.

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

<source lang="c">
/* Generated by dbus-binding-tool; do not edit! */
  /*... Listing cut for brevity ...*/
static
#ifdef G_HAVE_INLINE
inline
#endif
gboolean
org_maemo_Value_getvalue1 (DBusGProxy *proxy, gint* OUT_cur_value,
                                              GError **error)
{
  return dbus_g_proxy_call (proxy, "getvalue1", error, G_TYPE_INVALID,
                            G_TYPE_INT, OUT_cur_value, G_TYPE_INVALID);
}
  /*... Listing cut for brevity ...*/
static
#ifdef G_HAVE_INLINE
inline
#endif
gboolean
org_maemo_Value_setvalue1 (DBusGProxy *proxy, const gint IN_new_value,
                                              GError **error)
{
  return dbus_g_proxy_call (proxy, "setvalue1", error, G_TYPE_INT,
                            IN_new_value, G_TYPE_INVALID,
                            G_TYPE_INVALID);
}
</source>

The two functions presented above are both ''blocking'', which means that they 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 <code>_async</code>).

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 are converted into underscores (because C reserves the dot character for other uses), but otherwise the name is preserved (barring dashes in the name).

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

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

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

<source lang="c">
#include <glib.h>
#include <dbus/dbus-glib.h>
#include <stdlib.h> /* exit, EXIT_FAILURE */
#include <string.h> /* strcmp */
/* Pull the common symbolic defines. */
#include "common-defs.h"
/* Pull in the client stubs that were generated with
   dbus-binding-tool */
#include "value-client-stub.h"
</source>

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

<source lang="c">
/**
 * This function is called repeatedly from within the mainloop
 * timer launch code.
 *
 * The function starts with two statically initialized variables
 * (int and double) which are incremented after each time this
 * function runs and use the setvalue* remote methods to set the
 * new values. If the set methods fail, program is not aborted, but an
 * message is issued to the user describing the error.
 */
static gboolean timerCallback(DBusGProxy* remoteobj) {

/* Local values that we'll start updating to the remote object. */
  static gint localValue1 = -80;
  static gdouble localValue2 = -120.0;

GError* error = NULL;

/* Set the first value. */
  org_maemo_Value_setvalue1(remoteobj, localValue1, &error);
  if (error != NULL) {
    handleError("Failed to set value1", error->message, FALSE);
  } else {
    g_print(PROGNAME ":timerCallback Set value1 to %d\n", localValue1);
  }

/* If there was an error with the first, release the error, and
     don't attempt the second time. Also, don't add to the local
     values. We assume that errors from the first set are caused by
     server going off the D-Bus, but are hopeful that it comes
     back, and hence keep trying (returning TRUE). */
  if (error != NULL) {
    g_clear_error(&error);
    return TRUE;
  }

/* Now try to set the second value as well. */
  org_maemo_Value_setvalue2(remoteobj, localValue2, &error);
  if (error != NULL) {
    handleError("Failed to set value2", error->message, FALSE);
    g_clear_error(&error); /* Or g_error_free in this case. */
  } else {
    g_print(PROGNAME ":timerCallback Set value2 to %.3lf\n", localValue2);
  }

/* Step the local values forward. */
  localValue1 += 10;
  localValue2 += 10.0;

/* Tell the timer launcher that we want to remain on the timer
     call list in the future as well. Returning FALSE here stops
     the launch of this timer callback. */
  return TRUE;
}
</source>

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

<source lang="c">
/**
 * The test program itself.
 *
 * 1) Setup GType/GSignal
 * 2) Create GMainLoop object
 * 3) Connect to the Session D-Bus
 * 4) Create a proxy GObject for the remote Value object
 * 5) Start a timer that launches timerCallback once per second.
 * 6) Run main-loop (forever)
 */
int main(int argc, char** argv) {
  /* The D-Bus connection object. Provided by GLib/D-Bus wrappers. */
  DBusGConnection* bus;
  /* This represents the Value object locally (acting as a proxy
     for all method calls and signal delivery. */
  DBusGProxy* remoteValue;
  /* This refers to the GMainLoop object */
  GMainLoop* mainloop;
  GError* error = NULL;

/* Initialize the GType/GObject system. */
  g_type_init();

/* Create a new GMainLoop with default context (NULL) and initial
     state of "not running" (FALSE). */
  mainloop = g_main_loop_new(NULL, FALSE);
  /* Failure to create the main loop is fatal (for us). */
  if (mainloop == NULL) {
    handleError("Failed to create the mainloop", "Unknown (OOM?)",
                TRUE);
  }

g_print(PROGNAME ":main Connecting to Session D-Bus.\n");
  bus = dbus_g_bus_get(DBUS_BUS_SESSION, &error);
  if (error != NULL) {
    handleError("Couldn't connect to the Session bus", error->message,
                TRUE);
    /* Normally you'd have to also g_error_free() the error object
       but because the program terminates within handleError,
       it is not necessary here. */
  }

g_print(PROGNAME ":main Creating a GLib proxy object for Value.\n");

/* Create the proxy object that we are using to access the object
     on the server. If you use dbus_g_proxy_for_name_owner(),
     you are also notified when the server that implements the
     object is removed (or rather, the interface is removed). Because
     we do not care who actually implements the interface, we'll use the
     more common function. See the API documentation at
     http://maemo.org/api_refs/4.0/dbus/ for more details. */
  remoteValue =
    dbus_g_proxy_new_for_name(bus,
                              VALUE_SERVICE_NAME, /* name */
                              VALUE_SERVICE_OBJECT_PATH, /* obj path */
                              VALUE_SERVICE_INTERFACE /* interface */);
  if (remoteValue == NULL) {
    handleError("Couldn't create the proxy object",
                "Unknown(dbus_g_proxy_new_for_name)", TRUE);
  }

g_print(PROGNAME ":main Starting main loop (first timer in 1s).\n");

/* Register a timer callback that does RPC sets on the values.
     The userdata pointer is used to pass the proxy object to the
     callback so that it can launch modifications to the object. */
  g_timeout_add(1000, (GSourceFunc)timerCallback, remoteValue);

/* Run the program. */
  g_main_loop_run(mainloop);
  /* Because the main loop is not stopped (by this code), we should not
     ever get here. The program might abort() for other reasons. */

/* If it does, return failure as exit code. */
  return EXIT_FAILURE;
}
</source>

After building the client, start and execute it in the same terminal session where the server is still running:

<pre>
 [sbox-DIABLO_X86: ~/glib-dbus-sync] > make client
dbus-binding-tool --prefix=value_object --mode=glib-client \
 value-dbus-interface.xml > 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] > 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] > fg
run-standalone.sh ./server
[Ctrl+c]
</pre>

Because the client normally runs forever, it is now terminated and the server is 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 the [http://maemo.org/api_refs/5.0/5.0-final/dbus-glib/ D-Bus GLib Bindings Documentation].

== D-Bus Introspection ==

D-Bus supports a mechanism by which programs can interrogate the bus for existing well-known names and 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: <code>ListNames</code>, <code>GetNameOwner</code> and <code>Introspect</code>. The destination object must support the introspection interface in order to provide this information. If the <code>dbus-bindings-tool</code> is used, and the <code>GObject</code> is registered correctly, the service automatically supports introspection.

For the time being, D-Bus 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 you are planning to write your own tool, you must be prepared to parse XML data, because that is the format of results that the Introspect method returns.

[[Image:dbus-inspector-on-globalvalue-with-names.png|Image dbus-inspector-on-globalvalue-with-names]]Using DBUS Inspector on <code>GlobalValue</code> on a desktop system. Note that the version of <code>GlobalValue</code> used here also implements signals.

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

[[Category:Development]]
[[Category:Documentation]]
[[Category:Fremantle]]

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/DBus/Using_GLib_Wrappers_For_D-Bus"

Personal tools

Navigation

Views

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

@@ Line 13: / Line 13: @@
 Because the primary objective here is to make the object available over D-Bus, the example starts by covering one of the easiest way of achieving this: the dbus-bindings-tool. The tool generates a lot of the bindings code for both the client and server side. As input the 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 is copied into the generated stub code automatically by the tool). The first method is <code>setvalue1</code>, which gets one argument, <code>new_value</code>, which is an 32-bit signed integer: [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/value-dbus-interface.xml glib-dbus-sync/value-dbus-interface.xml]
+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 is copied into the generated stub code automatically by the tool). The first method is setvalue1, which gets one argument, new_value, which is an 32-bit signed integer: glib-dbus-sync/value-dbus-interface.xml
 <source lang="xml">
@@ Line 22: / Line 22: @@
 </source>
-Define each argument explicitly with the arg element. The type attribute is required because it defines the data type for the argument. Arguments are sometimes called parameters when they are 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 is out. If a method call does not return any value (returns <code>void</code>), no argument with the direction out needs to be specified.
+Define each argument explicitly with the arg element. The type attribute is required because it defines the data type for the argument. Arguments are sometimes called parameters when they are 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 is out. If a method call does not return any value (returns void), no argument with the direction out needs to be specified.
 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.
@@ Line 40: / Line 40: @@
 From the above list, it can be seen that setvalue1 accepts one 32-bit signed integer argument (<code>new_value</code>). The name of the argument affects the generated stub code prototypes (not the implementation), but is quite useful for documentation, and also for D-Bus introspection.
-The next step is the interface specification of another method: <code>getvalue1</code>, which returns 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: [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/value-dbus-interface.xml glib-dbus-sync/value-dbus-interface.xml]
+The next step is the interface specification of another method: <code>getvalue1</code>, which returns 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
 <source lang="xml">
@@ Line 53: / Line 53: @@
 Bind the methods to a specific (D-Bus) interface by placing the method elements within an interface element. The interface name attribute is optional but recommended, otherwise the interface is unnamed and provides less useful information on introspection.
-Multiple interfaces can be implemented in the same object, and if this is the case, the multiple interface elements are listed within the node element. The node element is the "top-level" element. In this case, only one explicit interface is implemented (the binding tools 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: [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/value-dbus-interface.xml glib-dbus-sync/value-dbus-interface.xml]
+Multiple interfaces can be implemented in the same object, and if this is the case, the multiple interface elements are listed within the node element. The node element is the "top-level" element. In this case, only one explicit interface is implemented (the binding tools 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
 <source lang="xml">
@@ Line 71: / Line 71: @@
 </source>
-Extend the minimal interface specification by adding the correct reference to the proper DTD. This allows validation tools to work automatically with the XML file. Methods are also added to manipulate the second value. The full interface file now contains comments, describing the purpose of the interface and the methods. This is highly recommended, if publishing the interface is planned at some point, as the bare XML does not carry semantic information. [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/value-dbus-interface.xml glib-dbus-sync/value-dbus-interface.xml]
+Extend the minimal interface specification by adding the correct reference to the proper DTD. This allows validation tools to work automatically with the XML file. Methods are also added to manipulate the second value. The full interface file now contains comments, describing the purpose of the interface and the methods. This is highly recommended, if publishing the interface is planned at some point, as the bare XML does not carry semantic information. glib-dbus-sync/value-dbus-interface.xml
 <source lang="xml">
@@ Line 120: / Line 120: @@
 </source>
-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 <code>DOCTYPE</code> processing directive.
+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, because DTD validation can only check for syntax and structure, but not for meaning or semantics.
-The next step is to add a target called <code>checkxml</code> to the <code>Makefile</code>, so that it can be run whenever the validity of the interface XML is to be checked. [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/Makefile glib-dbus-sync/Makefile]
+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
-<source lang="make">
+<source lang="c">
 # One extra target (which requires xmllint, from package libxml2-utils)
 # is available to verify the well-formedness and the structure of the
@@ Line 177: / Line 177: @@
 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 <code>checkxml</code>, the validation can be integrated into the process of the build. However, it is not always the best solution.
+If the makefile targets depend on checkxml, the validation can be integrated into the process of the build. However, it is not always  the best solution.
 ==Generating Automatic Stub Code ==
-The following step is to generate the "glue" code that implements the mapping from GLib into D-Bus. The generated code is used later on, but it is useful to see at this point what the <code>dbus-binding-tool</code> program generates.
+The following step is to generate the "glue" code that implements the mapping from GLib into D-Bus. The generated code is used later on, but it is useful to see at this point what the dbus-binding-tool program generates.
-Expand the <code>Makefile</code> to invoke the tool whenever the interface XML changes and store the resulting glue code separately for both the client and server. [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/Makefile glib-dbus-sync/Makefile]
+Expand the '''Makefile''' 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
-<source lang="make">
+<source lang="c">
 # Define a list of generated files so that they can be cleaned as well
 cleanfiles := value-client-stub.h \
@@ Line 210: / Line 210: @@
 </source>
-Pass two parameters for the <code>dbus-binding-tool</code> program. Use the <code>--prefix</code> parameter to tell which text is prefixed to all generated structure and function names. This helps to avoid namespace collisions when pulling the generated glue files back into the programs. The <code>value_object</code> is used because it seems like a logical prefix for the project. 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.
+Pass two parameters for the <code>dbus-binding-tool</code> program. Use the <code>--prefix</code> parameter to tell which text is prefixed to all generated structure and function names. This helps to avoid namespace collisions when pulling the generated glue files back into the programs. The value_object is used because it seems like a logical prefix for the project. 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 selects what kind of output the tool generates. At the moment, the tool only supports generating GLib/D-Bus bindings, but this might change in the future. Furthermore, select which "side" of the D-Bus the bindings are 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.
@@ Line 217: / Line 217: @@
 <pre>
-[sbox-DIABLO_X86: ~/glib-dbus-sync] > make value-server-stub.h value-client-stub.h
+ [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 > value-server-stub.h
+   value-dbus-interface.xml &gt; value-server-stub.h
 dbus-binding-tool --prefix=value_object --mode=glib-client \
-   value-dbus-interface.xml > value-client-stub.h
+   value-dbus-interface.xml &gt; value-client-stub.h
-[sbox-DIABLO_X86: ~/glib-dbus-sync] > ls -la value*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
 </pre>
-Check what the tool produced, starting with the server stub file: [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/value-server-stub.h glib-dbus-sync/value-server-stub.h]
+Check what the tool produced, starting with the server stub file: glib-dbus-sync/value-server-stub.h
 <source lang="c">
@@ Line 271: / Line 271: @@
 == 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 <code>GObject</code>. The per-instance structure contains the required "parent object" state (<code>GObject</code>), but also includes the two internal values (<code>value1</code> and <code>value2</code>), with which the rest of this example is concerned: [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/server.c glib-dbus-sync/server.c]
+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 (<code>value1</code> and <code>value2</code>), with which the rest of this example is concerned: glib-dbus-sync/server.c
 <source lang="c">
@@ Line 296: / Line 296: @@
 The convenience macros are defined in a way expected for all <code>GType</code>s. The <code>G_TYPE_</code> macros are defined in <code>GType</code> and include the magic by which the object implementation does not need to know much about the internal specifics of <code>GType</code>. The <code>GType</code> macros are described in the [http://maemo.org/api_refs/5.0/beta/gobject/ GObject API reference for GType].
-Some of the macros are used internally in this implementation later on. [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/server.c glib-dbus-sync/server.c]
+Some of the macros are used internally in this implementation later on. glib-dbus-sync/server.c
 <source lang="c">
@@ Line 331: / Line 331: @@
 The <code>dbus_g_object_type_install_info</code> function takes a pointer to the structure describing the D-Bus integration (<code>dbus_glib_value_object_object_info</code>), which is generated by <code>dbus-bindings-tool</code>. This function creates all the necessary runtime information for the <code>GType</code>, so the details can be left alone. It also attaches the introspection data to the <code>GType</code>, so that D-Bus introspection may return information on the interface that the object implements.
-The next functions to be implemented are the get and set functions, which allow us to inspect the interface as well. The names of the functions and their prototypes are ultimately dictated by <code>dbus-bindings-tool</code> generated stub header files. This means that if the interface XML is sufficiently changed, the code fails to build (because the generated stubs yield different prototypes): [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/server.c glib-dbus-sync/server.c]
+The next functions to be implemented are the get and set functions, which allow us to inspect the interface as well. The names of the functions and their prototypes are ultimately dictated by <code>dbus-bindings-tool</code> generated stub header files. This means that if the interface XML is sufficiently changed, the code fails to build (because the generated stubs yield different prototypes): glib-dbus-sync/server.c
 <source lang="c">
@@ Line 403: / Line 403: @@
 The GLib/D-Bus wrapper logic implements all the necessary parameter conversion from D-Bus into the functions, so it is only necessary to handle the GLib corresponding types (<code>gint</code> and <code>gdouble</code>). The method implementations always receive an object reference to the object as their first parameter, and a pointer to a place where to store new <code>GError</code> objects if the method decides that an error should be created. This error is then to be propagated back to the caller of the D-Bus method. This simple get/set example never sets errors, so the last parameter can be ignored here.
-Do not return the values in the conventional C way (by using <code>return someVal</code>), but instead the return values are written using the given pointers. The return value of the method is always a <code>gboolean</code>, signifying either success or failure. If failure (<code>FALSE</code>) is returned, create and setup a <code>GError</code> object, and store its address to the error location.
+Do not return the values in the conventional C way (by using return someVal), but instead the return values are written using the given pointers. The return value of the method is always a gboolean, signifying either success or failure. If failure (<code>FALSE</code>) is returned, create and setup a <code>GError</code> object, and store its address to the error location.
 == Publishing GType on D-Bus ==
@@ Line 409: / Line 409: @@
 Once the implementation is complete, an instance of the class must be published onto the D-Bus. This is done inside the main of the server example and involves performing a D-Bus method call on the bus.
-To ensure that the server and the client do not have to be changed, if the object or well-known names are changed later, the server and the client are put into a common header file that is used by both: [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/common-defs.h glib-dbus-sync/common-defs.h]
+To ensure that the server and the client do not have to be changed, if the object or well-known names are changed later, the server and the client are put into a common header file that is used by both: glib-dbus-sync/common-defs.h
 <source lang="c">
@@ Line 425: / Line 425: @@
 Before using any of the <code>GType</code> functions, the runtime system must be initialized by calling <code>g_type_init</code>. This creates the built-in types and sets up all the machinery necessary for creating custom types. When using GTK+, the function is called automatically if GTK+ is initialized. Because this example only uses GLib, the function must be called manually.
-After initializing the <code>GType</code> system, the next step is to open a connection to the session bus, which is used for the remainder of the publishing sequence: [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/ glib-dbus-sync/server.c]
+After initializing the <code>GType</code> system, the next step is to open a connection to the session bus, which is used for the remainder of the publishing sequence: glib-dbus-sync/server.c
 <source lang="c">
@@ Line 451: / Line 451: @@
 </source>
-For prospective clients to find the object on the session bus, attach the server to a well-known name by using the <code>RequestName</code> method call on the D-Bus server (over D-Bus). To target the server, create a GLib/D-Bus proxy object first: [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/server.c glib-dbus-sync/server.c]
+For prospective clients to find the object on the session bus, attach the server to a well-known name by using the <code>RequestName</code> method call on the D-Bus server (over D-Bus). To target the server, create a GLib/D-Bus proxy object first: glib-dbus-sync/server.c
 <source lang="c">
@@ Line 551: / Line 551: @@
 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, an instance of the <code>ValueObject</code> is created and published on the D-Bus: [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/server.c glib-dbus-sync/server.c]
+After the successful name registration, an instance of the <code>ValueObject</code> is created and published on the D-Bus: glib-dbus-sync/server.c
 <source lang="c">
@@ Line 592: / Line 592: @@
 All 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 gives this snippet: [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/Makefile glib-dbus-sync/Makefile]
+Implementing the dependencies and rules for the server and the generated stub code gives this snippet: glib-dbus-sync/Makefile
 <source lang="c">
@@ Line 607: / Line 607: @@
 </source>
-When implementing makefiles that separate compilation from linking, passing the target name (automatic variable <code>$@</code>) directly is not possible as the <code>PROGNAME</code>-define (because that expands into <code>server.o</code>, and it would look slightly silly if all the messages were prefixed with the name). Instead, use a GNU make function (<code>basename</code>) to strip any prefixes and suffixes out of the parameter. This way, the <code>PROGNAME</code> is set to server.
+When implementing makefiles that separate compilation from linking, passing the target name (automatic variable $@) directly is not possible as the PROGNAME-define (because that expands into server.o, and it would look slightly silly if all the messages were prefixed with the name). Instead, use a GNU make function (basename) to strip any prefixes and suffixes out of the parameter. This way, the PROGNAME is set to server.
 The next step is to build the server and start it:
 <pre>
-  [sbox-DIABLO_X86: ~/glib-dbus-sync] > make server
+  [sbox-DIABLO_X86: ~/glib-dbus-sync] &gt; make server
 dbus-binding-tool --prefix=value_object --mode=glib-server \
-   value-dbus-interface.xml > value-server-stub.h
+   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
@@ Line 620: / Line 620: @@
     -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] > run-standalone.sh ./server
+[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)
@@ Line 694: / Line 694: @@
 The <code>dbus-bindings-tool</code> (when run with the <code>--mode=glib-client</code> parameter) generates functions for each of the interface methods, and the functions handle data marshaling operations internally.
-Two generated stub functions are presented below, and they are used shortly: [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/value-client-stub.h glib-dbus-sync/value-client-stub.h]
+Two generated stub functions are presented below, and they are used shortly: glib-dbus-sync/value-client-stub.h
 <source lang="c">
@@ Line 729: / Line 729: @@
 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 <code>org_maemo_Value</code> prefix is taken from the interface XML file, from the name attribute of the interface element. All dots are converted into underscores (because C reserves the dot character for other uses), but otherwise the name is preserved (barring dashes in the name).
+The org_maemo_Value prefix is taken from the interface XML file, from the name attribute of the interface element. All dots are converted into underscores (because C reserves the dot character for other uses), but otherwise the name is preserved (barring dashes in the name).
 The rest of the function name is the method name for each method defined in the interface XML file.
-The first parameter for all the generated stub functions is always a pointer to a <code>DBusProxy</code> object, which is necessary to use with the GLib/D-Bus wrapper functions. After the proxy, a list of method parameters is passed. The binding tool prefixes the parameter names with either <code>IN_</code> or <code>OUT_</code> depending on the "direction" of the parameter. The rest of the parameter name is taken from the name attributed of the arg element for the method, or if not given, is automatically generated as arg0, arg1, etc. Input parameters are passed as values (unless they are complex or strings, in which case they are passed as pointers). Output parameters are always passed as pointers.
+The first parameter for all the generated stub functions is always a pointer to a <code>DBusProxy</code> object, which is necessary to use with the GLib/D-Bus wrapper functions. After the proxy, a list of method parameters is passed. The binding tool prefixes the parameter names with either IN_ or OUT_ depending on the "direction" of the parameter. The rest of the parameter name is taken from the name attributed of the arg element for the method, or if not given, is automatically generated as arg0, arg1, etc. Input parameters are passed as values (unless they are complex or strings, in which case they are passed as pointers). Output parameters are always passed as pointers.
-The functions always returns a <code>gboolean</code>, indicating failure or success, and if they fail, they also create and set the error pointer to an <code>GError</code> object which can then be checked for the reason for the error (unless the caller passed a <code>NULL</code> pointer for <code>error</code>, in which case the error object is not created). [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/client.c glib-dbus-sync/client.c]
+The functions always returns a gboolean, indicating failure or success, and if they fail, they also create and set the error pointer to an <code>GError</code> object which can then be checked for the reason for the error (unless the caller passed a <code>NULL</code> pointer for <code>error</code>, in which case the error object is not created). glib-dbus-sync/client.c
 <source lang="c">
@@ Line 749: / Line 749: @@
 </source>
-This allows the client code to use the stub code directly as follows: [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/client.c glib-dbus-sync/client.c]
+This allows the client code to use the stub code directly as follows: glib-dbus-sync/client.c
 <source lang="c">
@@ Line 808: / Line 808: @@
 </source>
-What is left is connecting to the correct D-Bus, creating a <code>GProxy</code> object which are done in the test program: [http://vcs.maemo.org/svn/maemoexamples/trunk/glib-dbus-sync/client.c glib-dbus-sync/client.c]
+What is left is connecting to the correct D-Bus, creating a <code>GProxy</code> object which are done in the test program: glib-dbus-sync/client.c
 <source lang="c">