Following our interview last month with Phil Thompson on PyQt, we spoke with the maintainer of PyKDE to discover the status of our own Python bindings. Read on for Jim Bublitz talking about how he was suckered into maintaining PyKDE, why you should use it and what his plans for the future are.
Kubuntu's new installer, Ubiquity, uses PyKDE.
Please introduce yourself and your role in KDE.
I'm Jim Bublitz. I maintain PyKDE - the Python language bindings for KDE.
What is PyKDE and why should I use it?
PyKDE allows you to access most of the essential classes and methods of kdelibs
from Python. I use it myself because it allows me to develop good-looking graphical
applications that are KDE compatible, and allows me to do it from Python, which I
find to be a much quicker and easier development environment than C++.
I like having Python bindings for KDE (as opposed to just Qt/PyQt) because KDE
provides additional more convenient and higher level widgets, dialogs, etc.
than Qt alone does. With GUI applications, speed is often not an issue, and
I doubt I'd see much improvement by going to C++. Most of PyKDE actually
runs in C++ space anyway - it's just invoking methods that takes place
How did PyKDE start?
Phil Thompson (who doe PyQt and created sip, which underlies PyQt and PyKDE) did
the original PyKDE for KDE 1.x.
How did you get involved?
In 2001, I was developing an application using PyKDE for KDE 1.x about the
time KDE 2.0 and Qt 2.0 were released. There was a minor problem with the
existing PyKDE version and it wasn't compatible with KDE 2.0, so I posted a
message to the PyKDE mailing list. Phil responded that he was no
longer able to maintain PyKDE or generate a version for KDE 2.0, and the
short of it is, he suckered me into doing PyKDE for KDE 2.0 - "just do the
parts you need and someone will pick up the rest" - it's not possible to do
PyKDE that way. You have to do the whole thing. Anyway, Phil provided a lot
of help and support for my initial relase and subsequent releases.
I'm probably not the best person to maintain PyKDE. I'm not a professional
programmer (but somewhat more knowledgeable than a "hobbyist"), and I
run a non-software business and have other commitments that make it
difficult to keep PyKDE current at all times. However, no one else has
volunteered to do it, so I keep at it (and enjoy it).
How much work is it to maintain?
It was pretty obvious from the beginning that keeping up with frequent
KDE releases would be the biggest problem, so after I did the initial
release manually, I started working on automating the process. It takes
about 10 minutes to generate a new PyKDE version automatically, and
maybe another couple of hours to touch up the errors from some of the
minor bugs in my software that I haven't gotten around to fixing. At one
point in time, I could have written a script to download the KDE source
and dump out a finished PyKDE with no intervention, but a few things
have broken since then.
Phil has continually worked to improve sip, and it seems like every
improvement breaks PyKDE in some way. On the other hand, a lot of the
improvements have been done to support C++ features in KDE that Qt
doesn't require, so I've added to Phil's workload a lot too.
The time consuming part is back-testing against different KDE versions and
different distributions. One of the nice things about the way Phil has
designed sip and the way we've evolved the build process and source distributions
is that it's relatively painless to have a single set of files build for all
combinations of Qt and KDE versions. That's important, because users and
distributions are never in sync with the versions they use, for example,
Debian Stable vs the latest SuSE release. For quite a while, we maintained
backward compatibility from Qt and KDE 2.0 up through Qt and KDE 3.x
versions. Even now, PyKDE should build with any KDE 3.x version and compatible
Qt version. In addition, we have to worry about a range of Python and
gcc versions as well.
There are still some users running KDE 3.0, for example, and I like the fact
that we can continue to support them. I'm currently running KDE 3.4 in production,
and only recently switched to that because of a hardware upgrade, but PyKDE includes
all of the changes through KDE 3.5.2 and should build with 3.5.3 and 3.5.4.
Debugging can be very time consuming because of the layers of code, the long PyKDE
build times (especially when I have to relegate it to a slower machine), and
unfamiliarity with some of the more complicated parts of the KDE API.
A large number of people have made significant contributions to PyKDE - either
reporting bugs, requesting features, writing examples, or working through coding problems.
The THANKS file for PyKDE has a lot of names, and I've probably missed a few too. Of course
PyKDE wouldn't exist at all without Qt, KDE and all the developers who have contributed
How complete is PyKDE?
It covers most of the major components of kdelibs. I've dropped support recently
for a few things like kjs and kdesu, because they didn't seem to be very useful from Python,
and nobody was using them that I'm aware of. Some things, like kparts, still
have a few problems that need addressing, and, for example, a user recently
contributed some nice enhancements to DCOP support. Some of the less-used
parts probably don't get the testing they need, but support is there for
kdecore, kdeui, kio, kfile, kmdi and most of the other kdelibs components.
I haven't computed the stats for PyKDE lately, but my automation stuff
generates something like 60,000 lines of intermediate code (*.sip files) and
all of PyKDE is well over 1 million lines of C++ code (generated by sip from
the intermediate code). And it's about as compact as it could be.
Do you have any plans for KDE 4?
At present I plan to implement PyKDE for KDE 4. The hard part - sip and PyQt
support - has already been accomplished by Phil. I've looked at Qt 4, but am far
from familiar with it at the moment, and from what I can tell, KDE 4's design
still needs to "settle down" a little before it makes sense to look at doing
bindings for it.
PyKDE will probably lag the KDE 4 release by a little - maybe a month of two.
There are a number of problems with working alpha and beta releases, and
it's probable that sip or PyQt will need some adjustments, but I don't
expect any major delays.
KDE 4 will also be a good excuse to rethink PyKDE and improve the process
of creating PyKDE, and there have been some discussions lately on the PyKDE
What is the relationship between the versions of PyKDE on riverbankcomputing.co.uk and the version in kdebindings?
I've never been able to schedule my PyKDE work reliably enough to stay in sync
with KDE's release schedules, so I've avoided putting PyKDE in the KDE CVS. Fortunately,
Simon Edwards was able to repackage PyKDE and maintain the kdebindings part of
it, and I really appreciate the work he's put in to that.
The kdebindings version lags my version of PyKDE by a little, but since KDE has matured,
the changes between versions of kdelibs have become less significant. I don't see that
as a problem for 99% of potential users or applications.
Are you paid for your work?
No, but I use PyKDE to write applications for my business (mostly accounting and similar
stuff at the moment, but other things in the past), so I get a "payoff" that way.
Do you know of any exciting users of PyKDE?
I've been pleased to see PyKDE-based apps popping in various places, and a little
embarrassed because of some of the problems in keeping PyKDE up to date and fixing
various problems. Simon's work has been important in providing a consistent platform
that allows people to distribute PyKDE-based apps. I haven't kept track in detail of
who's using it and where.
One piece of code that I haven't had time to look at yet is something Troy Melhase
has just made available at Google Code. It's a demo
of some of PyKDE's capabilities. Troy contributed some of the example code that
comes with PyKDE, and I'm sure pykde-sampler is very well done.
What is Eric?
Eric is an IDE/debugger for Python development, particularly PyQt and PyKDE development, but
not limited to those. It includes support for every software tool ever invented, even
Bicycle Repairman, CVS and subversion, and Qt Designer. Its creator and maintainer is
Detlev Offenbach, which, from the amount and quality of output, is probably a
programming collective rather than one individual. A Qt 4 version will be available soon.
I'm just an Eric fan and user - not developer.
Would you like to see more use of PyKDE in KDE?
Not so much PyKDE as increased use and easier interfacing to Python (and other
languages, like perl and Ruby) across KDE and KOffice. Generating bindings with sip is
almost trivially easy (once you get over the learning curve), but, for example,
most KDE plugins require loading a C++ (.so) lib - a lot of people writing
in Python either don't know or don't want to deal with C++.
For something like panel applets, we (mostly David Boddie) were able to figure out a
way to write a single .so lib and fool kicker into using it to load any Python-based
applet, but in general that approach doesn't work for most KDE apps, although it probably
could. It's also possible to develop tools that automatically create the .so and .la
files for Python programmers, but I'd prefer a cleaner approach.
DCOP is one way to accomplish some of that, but it often doesn't expose enough of
an application's API to be really useful. Plugins with bindings that understand
parts of an app's API can be a lot more useful, although something like OpenOffice's
Python-UNO bridge is pretty daunting for novice programmers and complicated to use
for just about anyone. KDE as a platform seems a lot cleaner and easier to use in
My goal would be to be able to use any major language the way Windows users can use
VBasic with that platform and its applications, or, hopefully, better. I certainly
would like more people to use PyKDE, but for some things (like scripting a spreadsheet),
PyKDE involves a lot of unnecessary overhead.