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 in Python.

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 to those.

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 mailing list.

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 that way.

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.

<  |  >