[PyKDE] PyKDE

[Jim Bublitz]

On 13-Dec-02 Julian Rockey wrote:
> Is PyKDE being maintained? I'd be interested if a KDE 3.1 version
> is under development, as I'd like to try to integrate PyKDE/QT
> into KDevelop 3.0  (Gideon).

You must be new here - people familiar with the list know better
than to ask that question, because it always leads to a long, boring
explanation (see below)
 
> In my (humble, obviously) opinion, Python as a scripting language
> could be as important to Unix/Linux as VB was to Windows (and I
> mean that as a good  thing...) Have there ever been discussions
> about whether to release PyKDE/QT with KDE's kdebindings
> package?


Long, Boring Explanation
========================

(I actually answer your questions somewhere near the end)

PyKDE is indeed still being maintained. There won't be a new
release until after KDE3.1 final is released. Here's a status
update, a really long, boring explanation:

For some time the sip files which sip uses to generate PyKDE have
been generated automatically via a very poorly written program that
produced a lot of errors on output, but still saved a immense
number of hours. About a month ago, I started rewriting that
program, and it is now a nice modular, actually debuggable,
semi-documented tool. At the moment, it will automatically generate
(except for some handwritten code) a complete set of sip files
(which means a complete set of bindings more or less) from a set of
h files for a lib. It has a few bugs, but nothing major that I'm
aware of. However, to be useful for PyKDE, the program has to be
able to do versioning - ie take a set of sip files from the
previous release and mix in the h files from the current KDE
release to produce a set of sip files that supports the current and
all previous KDE releases (PyKDE for KDE 2.1.1->3.1 consists of a
single set of sip files, just like PyQt does for its set of Qt
versions/platforms).

For reasons that would take even longer to explain, it makes sense
to rebuild PyKDE from 2.1.1 forward. If the tool works, this isn't
as bad as it sounds - once I get the first version (2.1.1) working,
each additional version should really only take about half a day,
especially with compile times as fast as they are now, and having
built everything through 3.0.4 once already.

So the point I'm at now is I have a set of sip files generated for
KDE 2.1.1. I need to clean those up (mostly handwrite some code -
actually cut and paste handwritten code from PyKDE-3.3.2) to get a
buildable PyKDE for KDE 2.1.1 (about 2/3 done). Next I need to
finish up the versioning code of the generator program, so that I
can produce more or less automatically KDE 2.1.2 ... KDE 3.1. The
time frame to complete that is a few weeks. I was shooting for
before the holidays, but it now looks like perhaps just after the
holidays. One big help will be that Phil just released sip/PyQt
3.5, so for once the KDE release will be after the last sip/PyQt
update - in the past it has made sense to wait for the sip/PyQt
release before releasing a new PyKDE.

There is kind of a master plan to all this (subject to very much
drastic change) that fits very well with your question about
KDevelop and comparison to VB. I agree completely that Python +
bindings could be far superior to VB for KDE in particular and
Linux/BSD in general. My goals (in chronological order) are:

Step 1. Release PyKDE for KDE 3.0.5 and KDE 3.1 - as soon after the
3.1 final release as possible.

Step 2. Clean up my sip file generator program, document it,
document sip generally as much as possible (probably update
Wilken's docs if he doesn't mind and perhaps add a tutorial). Every
few weeks someone posts to c.l.p asking about generating bindings
for some lib or other (the last was a few days ago for OpenH323).
There is at the moment no easy way to generate bindings (unless
you're familiar with sip, which at present is largely undocumented,
although a dream to use once you become familiar with it). The
basic idea is that if you have a lib/set of h files to bind, you
can write a short, simple project description file and the sip file
generator will automatically produce a set of sip files which can
be submitted to sip to generate the actual bindings. The generator
will also produce all the ancilliary files: build.py, Makefiles,
docs (in the current PyQt/PyKDE style) - everything except a small
amount of handwritten code (which should be covered exhaustively in
a tutorial or HOW-TO). If when this is working the people doing
packaging can see a way to add scripts to generate RPMs and deb
files, that would make it nearly perfect (except for all the bugs
I've probably coded in already). Target date is late Q1/early Q2
(lots of docs to write). Note that if this works, future PyKDE
releases should be achieveable in a few days after a KDE release.

(2) now means that any C/C++ libs can be bound for Python - in
theory it should be able to generate bindings for any KDE lib
(not just the basic libs as now - arts, games, whatever), or even
for something as divergent as GTK++ or Gnome (not looking to step
on other projects, though - just saying it might be possible).
Right now, it takes about 1/2 hour to write the project description
file for PyKDE, two minutes to generate all sip files, and about
two minutes for sip to generate bindings (handwritten code still
takes some time, but most of that is complete after the first
version is done). After that it's (in theory) compile, link, use
which if this works shouldn't take more than 20 minutes, so about
an hour to generate all of PyKDE (which is pretty big as far as
bindings/Python modules go). I'd be happy if the real world result
was 20 or 30 hours, which is probably closer to what reality will
be.

Step 3. Last spring I had a mostly working Python plug-in for
KSpread (KOffice 1.1). I could launch Python scripts automatically
from KSpread to operate on a spreadsheet, load multiple
spreadsheets, and even extend KSpread's built-in formulas with
Python scripts (eg - write a script that computes some function
"foo (x, y)", and then in a spreadsheet cell, enter =foo("a1",
"c6")) Rather than a complete set of KSpread bindings (huge) this
was a simple set of wrappers - about 200K not including the Python
interpreter (a little over 1MB total) - pretty lightweight and from
the tests I did slightly faster/slower/the same as native KSpread
built-in menu item/function calls. Python won't be comparable to VB
until you can use it to script things like spreadsheets, word
processors, etc. It ain't that hard (at least for KOffice),
especially with a tool as in (2) above. You can, of course, import
any Python module into scripts used this way.

In getting to KOffice 1.2, there have been some changes which break
what I wrote previously, and I've been holding off until 1.2 was
finalized. Also, I believe Python 2.3 will be a dynamic lib
instead of the current static lib, which changes things slightly.
There are also some possible problems using the present build
system that PyKDE/PyQt use, because KDE likes libtool libs for
plugins, but that should be solvable too.

The target date for accomplishing this is some time in the future.

Step 4. Python achieves world domination (some time after step 3)

Somewhere in there, PyKDE needs a lot better set of
examples/program templates, and a lot better testing too. (2) and
(3) mean lots of docs and examples to make (2) developer friendly
and (3) newbie friendly.

->>> Actual answers to questions here <<<-

So, to answer your questions: I would be thrilled to integrate
PyKDE into KDevelop (PyQt integration wouldn't be much different)
and would be happy to provide any assistance I can (email me
privately if necessary). I agree that Python can be a superior
replacement for VB. Both of those fit in with the master plan
nicely.

As far as putting PyKDE in kdebindings - I don't think that's
workable, at least not under the (reasonable) conditions KDE would
want, like putting PyKDE in CVS, for example. One issue is control,
which I'm reluctant to give up at the moment; another issue is that
the development system for PyKDE isn't really compatible with a CVS
type system - PyKDE isn't developed incrementally for the most
part, and at the moment isn't set up for team development (I'm not
anti-social, just have had very few people volunteer to help),
Also, I don't like CVS (mostly because I've never used it much).

*** Please keep in mind that everything except PyKDE is vaporware.

Aren't you glad you asked?

Jim