Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)

[Jim Bublitz]

On Sunday 30 March 2008 03:44, Alexander Dymo wrote:
> Once again, we'd better concentrate on writing great software. Reusing
> the code, using existing free software as much as possible is one of
> the ways to write great software. Why care about dependencies then?
> Let's let people making distros think about that.

Simon Edwards pointed me to this discussion - Simon maintains the KDE svn 
version of PyKDE and uic for PyKDE, I maintain the tarball version that's 
available at riverbankcomputing.com and write the tool that generates PyKDE 
sip files from the KDE h files. Phil Thompson is the author of PyQt and sip, 
which generates the C++ bindings from sip files, and is the runtime that 
allows the bindings to function. I've been doing PyKDE since late KDE2, Simon 
since late KDE3 - Phil has done sip/PyQt and the original PyKDE since early 
KDE1 at least. Most of the large distros and FreeBSD (and sometimes Solaris) 
have packagers.

I'm the guy who doesn't keep PyKDE up-to-date with KDE. Simon now has the 
tools to generate new PyKDE versions, so that should be less of a problem. If 
KDE maintains strict binary compatibility, that isn't much of a problem at 
all, because PyKDE lagging KDE simply means new classes/methods aren't picked 
up - previous apps should still work. However, one missing symbol in kdelibs 
(it happens) will break part or all of PyKDE if it's in one of the libs PyKDE 
binds.

PyKDE probably has bugs. I just fixed KCoreConfigSkeletion, which is broken in 
the current PyKDE release. PyKDE bugs get fixed either when I write an app 
using it and find a bug, or, as in the case of KCoreConfigSkeleton, someone 
else finds it. I'd love to have unit testing for all of PyKDE (the C++ test 
code isn't usable for PyKDE), but PyKDE binds about 600 classes and 10k 
methods. So the person who suggested that more apps using PyKDE would make it 
better is essentially correct. Some of the nicest improvements have been 
user-supplied.

I'm agnostic about whether KDE should have a core Python dependency. I agree 
with Alexander's earlier post about Ruby and Python as application languages 
- everything I write - PyKDE generation tools, my business accounting 
software, other stuff - is in Python. There's a great Python/PyQt/PyKDE IDE 
done by Detlev Offenbach called eric4, which includes a debugger that never 
crashes - if I hated Python, that would be enough motivation for me to use 
it. 

However I wouldn't overlook the "scripting" part of Python either. While PyKDE 
is a lot of overhead at runtime for the first instance (the 8MB cited sounds 
right, or maybe a little low) for a lot of people , the convenience or speed 
of development outweighs that. One of the most helpful things KDE could do to 
support other languages (without acquiring dependencies) would be to make 
plugins and similar things more easily writeable in other languages - for 
example, instead of requiring a specific .so lib, allow an .so lib that knows 
how to load an arbitrary Python script along with the interpreter (ie - pass 
the script name rather than looking for a specifically named .so lib). KDE3  
Panel applets and extensions allowed that. You can't create .so libs from 
Python.

I haven't looked at kross much yet, and maybe that will solve some of the 
problems, but some people would like to write plasmoids or ioslaves or other 
plugins in languages other than C++ and not have to write a C++ lib to use 
them. There were kate plugins using PyKDE for KDE3 and the same author may do 
them for KDE4.

As far as porting to OLPC or other devices, I don't have much to contribute 
there, except to note that PyQt was available quite a while ago for the Sharp 
Zaurus (I believe Sharp - or someone - paid for the port). 

I'm only subscribed here temporarily, so feel free to email me if I don't 
respond to something.

Jim