[dot] Jim Bublitz Talks About PyKDE

[Dot Stories]

URL: http://dot.kde.org/1157841422/

From: Jonathan Riddell <>
Dept: snake!
Date: Saturday 09/Sep/2006, @15:37

Jim Bublitz Talks About PyKDE
=============================

   Following our interview last month [http://dot.kde.org/1155075248/]
with Phil Thompson on PyQt, we spoke with the maintainer of PyKDE to
discover that 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 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
[http://mats.imk.fraunhofer.de/pipermail/pykde/2006-September/014001.html]
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
[http://code.google.com/p/pykde-sampler]. 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 [http://www.die-offenbachs.de/detlev/eric3.html] 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.
[http://mats.imk.fraunhofer.de/pipermail/pykde/2006-September/013985.html]

     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.