[PyKDE] QtDBus Support in PyQt

Jim Bublitz jbublitz at nwinternet.com
Sun Oct 29 01:11:19 GMT 2006

On Saturday 28 October 2006 03:13, Phil Thompson wrote:

> > DBUS completely replaces dcop in KDE4. I'm currently testing an up to
> > date version of KDE/trunk that uses DBUS as interprocess communication. I
> > haven't looked at the code, but I assume that everywhere there was a DCOP
> > reference there is now a QtDBus reference.
> Obviously you don't have to have the same binding implementing each end of
> a DBus call. The problem for PyKDE4 is if KDE4 includes some funky classes
> that everyone wants to use but requires the QtDBus API to be exposed.  If
> that proves to be the case then Jim and I can discuss it at the time. If
> that then requires QtDBus to be wrapped then that's what I'll do.

The situation is that if DBUS were just a straight replacement for DCOP, it 
wouldn't be much of a problem. It wouldn't be that difficult to pull DCOP out 
of PyKDE, and except for the lack of DCOP support, nothing much would change 
in PyKDE's API. I think there's a possibility that DBUS will be more exposed 
in KDE4 than DCOP was in earlier versions (for example, the startService* 
methods are using DBUS), but how PyKDE handles it can take a lot of different 

We tend to do "straight-up" bindings for Qt and KDE, where everything possible 
gets included and in a format that's fairly identical to the C++ API 
(allowing for some Pythonic differences, like Python lists instead of QList). 
But there are a range of other options, like not supporting something at all, 
or writing a PyKDE specific wrapper to interface to the C++ API, or ignoring 
a class that's hard to deal with, in addition to just doing a one-to-one 
binding of the C++ API.

I prefer the approach we use now, but that doesn't mean it's always the best 
way to accomplish something, and like Phil, I'm willing to wait and see what 
the implementation really looks like before deciding whether or how to 
support it. 


More information about the PyQt mailing list