So it turns out that the python dbus bindings just use glib - this means
that if you're using gtk2reactor, you can use dbus and it all Just Works.
This is very cool. It would be nice if there was a way to say (in dbus)
"Give me any pending event" in a non-blocking way -- we could then
write something similar to the current wxsupport module and use dbus
from any reactor. I'm not sure that this would be all that easy, as
dbus supplies bindings to other event loops rather than to the raw
network layer - but it's something that's probably worth looking into
Expect to see shtoom getting all dbussed up in the near future. ;)
On Sunday 01 May 2005 18:46, Anthony Baxter wrote:
So it turns out that the python dbus bindings just use glib - this means that if you're using gtk2reactor, you can use dbus and it all Just Works.
Hm. I spoke too soon. The server-side of it works fine (having code called
from dbus), but the client-side still needs work to make it work correctly
with Twisted. Working on it...
So I've got a version of the client-side that seems to work fine checked into
the sandbox/anthony/dbus directory. It's a bit messier than I'd like because
of the design of the current bindings for dbus-python - I'll follow up with
the dbus maintainers to figure out a better way to make it work. There's a
version of the example client and server modified to work with t_i_dbus.py
in the sandbox. Next up: test cases and docs.
Get it from:
I'm open to ideas on how to distribute this - as a separate project? It seems
to me like twisted.dbus is one place for it, or else twisted.internet.dbus?
The code works with dbus-0.33 (the current released version) - dbus in CVS
looks like it's being chopped and changed a lot, so it's quite probably not
going to work with that.
Also - currently the code will only work under gtk2reactor - the python dbus
bindings use the glib event loop. It would be nice to make the code event loop
agnostic, but I suspect that would involve a whole pile of new code.
Comments, bug reports, &c welcome.