[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
forms.
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.
Jim
More information about the PyQt
mailing list