[PyKDE] QtDBus Support in PyQt

[Phil Thompson]

On Saturday 28 October 2006 3:38 am, Mathieu Bouchard wrote:
> On Friday 27 October 2006 15:53, Jim Bublitz wrote:
> > On Friday 27 October 2006 10:51, Phil Thompson wrote:
> > > After working on this for a little while I've decided that I will not
> > > support QtDBus in PyQt. Reasons are...
> > >
> > > - A standard set DBus Python bindings already exist. These are still in
> > > active development but the current maintainer seems to be doing a good
> > > job, both in terms of backwards compatibility and ensuring they are
> > > Pythonic.
>
> Last commit is from 3 months ago.

I was referring to Simon McVittie's work, possibly for v0.8.

> Current python bindings only supports 
> glib main loop. So, if you want to create an application that acts as a
> d-bus server, you must use glib for now. The author has mentionned that he
> will add support for generic loops, but has never mentionned Qt. Since
> using glib main loop for d-bus support and another for Qt support is
> impossible, there is a problem.

Even with Qt 4.2's support for the glib main loop? Anyway, I've offered my 
help in adding support for the Qt loop - I think that's a better use of my 
time.

> Currently, you can only create applications that sends d-bus signals using
> python and Qt.
>
> > > - QtDBus is more difficult to wrap than the rest of Qt because of it's
> > > use of templates and its own type system. Not impossible to wrap - but
> > > there would be a list of "things to be aware of" and "differences
> > > between Qt and PyQt".
>
> There are already "things to be aware of" when using signals / slots using
> PyQt

That's a short list, this would be somewhat longer.

> > > - The extra work required would delay the release of PyQt v4.1.
> > >
> > > - As QtDBus is new to most people there isn't a large body of C++
> > > experience and code that could be ported to Python.
>
> I have not tried the C++ part of the QtDBus api because I was waiting for
> the PyQt version (For now, my only Qt/KDE applications are PyQt/PyKDE
> ones).
>
> > > I'm happy to reconsider this in the unlikely event that the standard
> > > Python bindings prove inadequate.
> >
> > At the moment, it isn't clear to me exactly how DBUS and QtDBus will be
> > integrated into KDE4. The KDE4 source/binaries I have really only
> > reference QtDBus in klauncher, and that doesn't appear to work at the
> > moment (although the source and  binaries I have are over a month old, so
> > that's probably changed).
> >
> > As I have absolutely no familiarity with DBUS, I'll have to wait and see
> > how it's implemented in KDE4 and then figure out what support I'll
> > provide. It may be supporting only parts of DBUS or providing something
> > similar to the DCOP extensions in the current PyKDE.
>
> 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.

Phil