Python <--> d-bus <--> c++ woes

[Simon McVittie]

On 07/03/13 01:27, Kip Warner wrote:
>> If you like GLib (which it seems you use in your Python code
>> already), please look at GDBus (part of GIO since 2.26), which does a
>> lot more of the hard work for you.
> 
> However, I am still confused about the difference between libdbus-glib
> and GDBus. Is the latter a command line tool and the former the runtime
> library that provides the GLib implementation of DBus? If so, I believe
> I just need to query pkg-config with "dbus-glib".

C libraries for use from C/C++
==============================

libdbus (libdbus-1.so.3, pkg-config: dbus-1, C naming convention:
dbus_foo()) is the library provided by the reference implementation of
D-Bus.

dbus-glib (libdbus-glib-1.so.2, pkg-config: dbus-glib-1, C naming
convention: dbus_g_foo()) is a deprecated GLib binding (wrapper) for
libdbus. It's "the old way" to use D-Bus in GLib applications.

GDBus (part of GIO: libgio-2.0.so.0, pkg-config: gio-2.0, C naming
convention: g_dbus_foo()) is a D-Bus library that can be used as an
alternative to the combination of libdbus and dbus-glib. It's "the new
way" to use D-Bus in GLib applications.

All three are written in C themselves, but can be used from C++.

command-line things
===================

gdbus (without the capital letters) is a command-line tool provided by
GIO, which uses GDBus to do things on D-Bus. You might find it useful
for debugging, but it's not directly relevant.

Python
======

dbus-python ("import dbus") is a wrapper around libdbus. It also
contains a wrapper around part of dbus-glib ("import
dbus.mainloop.glib"), which you need to use unless you have an
alternative main-loop-integration module (like the one from Qt). It
supports Python 3, but only if you have a very recent version.

GObject-Introspection ("import gi.repository.Something") is a way to use
"most" GObject-based libraries from high-level languages like Python and
Javascript, with an API based on their C API. dbus-glib is not available
in this way, but GDBus is.

> If it's as simple as
> just changing the import with the signatures remaining the same, then
> that would be awesome.

No, the Python API for GDBus is not the same as dbus-python. I think
GDBus is better-designed, but you would have to do some porting to use it.

> Because my application runs off of a removable optical
> media, activated via XDG's autostart on insert, the needed runtime
> environment has to be setup via the disc's autorun.sh which invokes by
> Python application on the disc which is in turn dependent on the user's
> installed runtimes. As I understand it, the .service file needs to be on
> the user's system already, correct?

Yeah, this might mean you can't use service activation, unfortunately.

Still, switching from using a signal to using a method call would mean
you always get feedback - either from the dbus-daemon, or from the app -
on whether the C++ app is ready yet.

>> Use GDBus. Seriously. :-)
> 
> I'd love to, but which packages do I need installed in order to use the
> API on my distro (Xubuntu 12.04)?

On Debian/Ubuntu, the runtime library, libgio-2.0.so.0, is part of the
libglib2.0-0 package. Gtk depends on GIO, so it's widely-installed
(GNOME, XFCE and Firefox users will certainly have it).

Ubuntu has had a sufficiently recent version of GIO since 11.10.