D-Bus code is incompatible with forthcoming dbus-python 0.80, and uses non-public API
I'm currently working on a rewrite of the dbus-python bindings, replacing the Pyrex module dbus_bindings with C code and changing the API where necessary to make the bindings more Pythonic. In practice, most Python D-Bus apps will continue to work with my rewrite, which is going to be released as version 0.80 (I released 0.80rc2 today).
However, the D-Bus code in Gajim uses some interfaces which were never meant to be part of the public API; these will stop working with dbus-python 0.80. The attached patches (untested) should at least get you started on porting gajim to dbus-python 0.80, in a way that will still work on dbus-python 0.60.
Specific issues:
-
dbus_bindings is not public API, and will go away. You can address most of this by just replacing "dbus.dbus_bindings.DBusException" with "dbus.DBusException" (this works in something like 0.40 and up).
-
In the remote control, you seem to be emitting signals using a much lower-level interface than is intended. The normal way to do this is by decorating a function of the same name as the signal with dbus.service.signal, then calling it (see my patch).
-
There is no such thing as None in the D-Bus world. You seem to represent it as the integer 0, which seems likely to cause confusion in future!
-
In general, it's unclear what you intend the signature of signals and methods to be. Part of designing a D-Bus interface is specifying the types of the arguments and return values for your methods and signals - see the Galago notifications spec (http://www.galago-project.org/specs/notification/0.9/x408.html) or the Telepathy spec (http://telepathy.freedesktop.org/spec.html) for some good examples.
-
The API for Variants has changed - there's no longer a Variant class, to make method arguments and return values consistent and unambiguous. Marking dicts and arrays with a signature that includes 'v' should achieve what you want to do.