P. Durante shackan at gmail.com
Thu Oct 12 11:26:25 PDT 2006

On 10/12/06, Peter Clifton <pcjc2 at cam.ac.uk> wrote:
> Hi,
> I'm in the situation where I need to provide dbus support in an
> application, where the GUI front end of the application is pluggable,
> and can either be GTK, Lesstif, or other. Each has its own mainloop and
> way of doing things.
> I've currently got GTK only support working. The code is very simple,
> there are only two methods.
> Is there a standard solution for coding a more generic implementation
> using the libdbus C API on its own?
yes and no, I've written dbus-c++ specifically for that pourpose, it
sits directly on top of libdbus and doesn't need any other external
library, but it's in c++ so you may or may not be comfortable with it

> All the pluggable GUIs in the application can be requested to provide
> timer callbacks, and file descriptor monitoring callbacks.
> What would be really nice would be an API, slightly higher level than
> the RAW C API, but providing asynchronous functions via a function
> pointer based callback system. (Perhaps marshallers or similar would
> still be needed).
> Setting up this API would require the app to register whatever
> file-descriptor and timer callbacks that the dbus part asks it to, and
> the rest should be simple.
> I was wondering if we could use a code generator of sorts to provide the
> glue, much as dbus-binding-tool does for the glib stuff.
dbus-c++ has a tool to generate c++ code for a dbus service (including
introspection data) from its xml description, you can then include
those headers and implement your methods, the library will call the
appropriate method whenever someone on the bus invokes it (or throw an
error if no such method exists, of course)

this is an example xml file

and its implementation

(all the *-glue.h files are automatically generated at compile time)

one missing feature is the generation of client-side stubs, but since
you're using python for that part shouldn't be a problem

> Where do the DBUS people stand on this type of problem... I need a main
> loop independent DBUS library, which is ideally a little friendlier to
> use than raw libdbus.
dbus-c++ implements its own mainloop, timers and watches, but you can
easily use a different mainloop implementation: just subclass
DBus::Dispatcher, DBus::Watch and DBus::Timer to use what you see fit
( boost, Qt, gtkmm or anything else ) and when you init the program
you do something like

  DBus::default_dispatcher = new DBusGtkDispatcher();
else if(use_qt)
  DBus::default_dispatcher = new DBusQtDispatcher();
  DBus::default_dispatcher = new DBus::BusDispatcher();


and somewhere else

unfortunately there's no official release nor formal documentation
yet, code can be checked out with subversion with
svn --username guest --password guest --non-interactive co


More information about the dbus mailing list