To be honest I'm not all that happy with the current situation. Riverbank Computing, basically Phil Thompson, has done an excellent job developing SIP and PyQt over the last 10 years and providing a Free Software (GPL) version which PyKDE is built on. Phil has also done an excellent job of providing answers to my queries, basically as a free service to KDE and the FOSS community. Having two competing Python bindings for Qt is a waste of resources and is generally disruptive to the community at large. Seeing the future of Riverbank and the good working relationship between it and KDE jeopardised is not something that appeals to me. I am disappointed that no kind of cooperative agreement could be reached between Nokia and Riverbank Computing.

On the technical side, PySide is just starting out and has a long way to go before it is as mature as PyQt and is a viable replacement for it. This is only natural. Bindings development is not easy -- just ask Richard Dale, he's been at it for years. (As a point of interest Nokia could have saved themselves a lot of effort by building on top of Richard's Smoke libraries/tools.) It will be interesting to see how PySide progresses and what happens in Python / Qt community. In the short term at least, PyKDE will continue to be developed on the mature SIP/PyQt.

KDE 4.3 is out, I'm vacationed, and now is a good time to explain share same of the things I would like to get done in PyKDE for KDE 4.4.

The main feature I want in KDE 4.4 is PyKDE support for Python 3. Snapshots of PyQt have supported Python 3 for a while now and from the reports I've heard the transition isn't too difficult and it is fairly straight forward to support both Python 2 and Python 3 using the same bindings (.sip) files. PyKDE support for Python 2 would remain of course until interest waned enough that I could drop it without upsetting too many people. One welcome change with moving to a PyQt/PyKDE on Python 3 is that we can use the simpler and more "Pythonic" PyQt API which eliminates QString and QStringList and QVariant. Instead of dealing with QStrings and Python strings inside the same program, you'll just have Python strings and things will be converted automatically.

The biggest problem which I foresee with supporting Python 3 is how to handle things like Python based plugins in system-settings and our desktop shell Plasma. The problem is that it is not practical to embed a Python 2 interpreter inside an application (e.g. "plasma-desktop") and a Python 3 interpreter at the same time. What this means is that you can't run Python 2 plasmoids at the same time with Python 3 plasmoids. One solution is to just say that only Python 2 is supported for plasmoids. This might work for a while, but in the long term Python 2 is going away. The other solution is to... ummm aaahh... I guess... say that version 4.X of KDE will only support Python 3 plasmoids, "Port or Die" would be the motto. That is not an option I'm really looking forward to either. If any plasmoid programmers, users or distro people have thoughts about this, then please speak up. I could really use some input on this issue.

As for wider binding coverage, I've had a request to make some bindings for most of the kggz* libraries in KDE's games module. So I'll make that happen (probably in playground and for KDE 4.3 initially). And I remember someone a long time ago on IRC requesting the ability for make Okular plugins with Python. If this is still (strongly) desired then get in touch with me (read: nag me and/or grovel as necessary).

I also want to spend some time on tooling to help with updating all of the bindings. The tool "twine" in kdesupport is used for bulk updating all of the .sip files which describe the KDE APIs for SIP which actually generates the bindings code. It was made by my PyKDE hacking predecessor and works quite well but it could use some refactoring and changes to help better match the workflow that I now use for development.

This year at GCDS I had the pleasure of meeting Gökmen and Gökçen (pronounced “Gerkman” and “Gerkchan” with hard Gees not Jays). They are part of a relatively small team of around 15 developers who are sponsored by the Turkish government work on a Turkish Linux distribution called Pardus. It is a KDE focused distribution which has been around since the end of 2005. What makes this distribution so interesting is the system tools and configuration tools which they've developed based heavily on Python, PyQt and PyKDE.

Here is a run down on the custom tools that I'm aware of and my impression thereof. I'm getting most of this information from the document “Python in Pardus” [1], my discussions with G & G, and what I've seen from playing a bit with the current RC2 inside Virtual Box.

YALI is their “Yet Another Linux Installer” and is Python and PyQt based. Using it this afternoon it appeared quite polished and no more complicated than the typical Kubuntu install. The Pardus artwork leans toward “cartoon”-ish and less towards photo realistic like the standard KDE 4 artwork. The only blemishes I saw during the install were limited to a couple of English grammar problems and awkward sentences.

System boot and initialisation is done using a Python based system called Mudur which replaces the mass of shell scripts which make up the typical Linux boot system. This, I'm told, provides a simple and understandable boot system. They claim to be able to boot to KDM in around 15-20 seconds, although I can't really say if this is true since I've only used it in a virtual environment.

Instead of RPM or Debian dpkg, Pardus has its own package manager called PiSi written in, yes, Python. It appears to be quite complete and includes a lot of functionality in one place which is often spread amongst separate programs on other packaging systems. The package scripts for building the packages are just little Python scripts. The packages can also contain Python scripts for performing updates (e.g. converting old settings into a new format etc). Also package updates are done by transmitting only the deltas between package versions. After I installed the RC2, I updated two packages and it downloaded 34 Kb. Slick. PiSi also includes a GUI based on PyKDE. It looks quite good and suitable for you're average user, and not entirely unlike KPackageKit.

The system configuration such as services/daemons, network connections, users and groups etc is managed by Çomar. From what I understand, it is a daemon (written in C) which sits on Dbus and centrally manages the system configuration, spawning Python processes to handle the actual work of changing and updating the configuration. There is a Python API which applications use to change the configuration and communicate with Çomar. Çomar can also send notification messages out to interested applications when the configuration changes. Gökmen demonstrated how changes to the wireless configuration were immediately reflected in their wireless plasmoid. There also a whole host of GUI configuration modules for KDE's “System Settings” written using PyKDE and Çomar.

Also, after I logged in on my Virtual Box install for the first time, I spotted a settings migration wizard and a desktop personalisation wizard for doing basic customisations such as double or single click mouse, type of menu in the K-menu etc.

As a Python fan and the main developer/maintainer of PyKDE, it certainly gives me that warm fuzzy feeling inside to see Python, PyQt and PyKDE put to such great use. It is also very impressive to see how such a small team of developers can put together such an impressive distribution. It is a great demonstration of why it is important to choose the right tool for the job. As one of the developers said to me, Pardus would not exist without PyQt and PyKDE.

The task for the future is to see how we, KDE and Pardus, can better work together to share code and make sure that more things can go up stream into KDE. The next major release of Pardus is due in about two weeks, is KDE 4.2 based and is definitely worth checking out. Keep up the good work Pardus!

[1] This document appears to be a couple years old.

Roberto Alsina recently posted a series of tutorials about Python and PyQt on his blog. I don't think they appeared on Planet KDE, so I'm forwarding them on. It covers typical Qt GUI programming using Qt Designer.

Most of the material is directly relevant if you want to develop KDE applications using Python, PyQt and PyKDE. Some differences of note are:

• KDE widgets - KDE has many widgets that replace standard Qt widgets and extend them with better integration with the KDE desktop and more functionality. Assuming you've got the right packages installed, you should have extra KDE widgets available inside Qt Designer.
• pykdeuic4 - The pyuic4 tool doesn't understand or support KDE's widgets. Use pykdeuic4 instead. It's basically pyuic4 with added KDE support.
• XMLGUI for menus and toolbars - KDE has support for defining menus, menu items and toolbars in an external XML file which will automatically be used if your application uses the KXmlGuiWindow class for its main window. This makes it easy for people to customise your application and saves you from having to write a lot of tedious and boring set up code.
• Build system - Python takes a pretty low ceremony approach to most things including build systems. Usually you don't need one, except perhaps during installation and/or packaging. In PyKDE in the kdebindings module, there should be an example Python project and directory called tools/cmake_project (exact location depends on your distribution). It is a basic project template which uses the CMake build system to correctly install your application and its data files, and doing things like generating .pyc files, and compiling .ui files to .py. It is a good base which can be expanded and customised. Some prior knowledge of CMake is required though.
• Resources - We, or at least I, don't use Qt style resources for handling images and data files etc. In a KDE application you'll be installing your files, possibly using CMake and using the methods on the KStandardDirs class (via KGlobal.dirs()) to locate your data files.

Here are the links. Thanks Roberto!

Session 1
Session 2
Session 3
Session 4
Session 5

In a great demonstration that not only do great minds think alike, they can also subconsciously syncronise to attack the same problem, Luca Beltrame and I started work on our own tutorials about writing Plasma applets using Python at exactly the same time and day this weekend. We've coordinated ourselves and now there are 3 new tutorials about programming Plasma applets with Python up on techbase. The first tutorial by myself is an introduction to the whole work cycle of creating an applet. Luca continues in the second tutorial with how to use Plasma widgets in an applet. And today I've written another tutorial about how to use DataEngines in an applet.

All three are available from the Plasma tutorials page on KDE techbase.

As always KDE isn't a spectator sport, so you are welcome to add to the tutorials on techbase. Enjoy.

I landed the Python script engine for Plasma in KDE trunk about a week ago and already and the keen and excitable among us have been franticly trying to get it all set up and installed. rgreening said it best on IRC "I've been wanting this sooooooooooooooooooooooooo bad". Now that's what I call an endorsement. So if you are running KDE trunk out of subversion and you want to have a go at the Python support then you can have a look at this wiki page which I hastily wrote which describes what needs to be installed and in which order:

http://techbase.kde.org/Getting_Started/Build/KDE4/Python_Support

It was hastily done, so you if you have more detail or information then please add it to the page.

About the Python support in Plasma itself. Right now there is a test/demo Python plasmoid (Pythoid!) in svn. You can guess which common time-keeping instrument this plasmoid displays. There is also a data engine which implements a simple time service. Runners are currently not in there but shouldn't be too hard to do (volunteers?). Also there are Python bindings for all of the plasma API. (Note that the bindings are not automatically updated from the C++ headers. They can sometimes lag a bit behind the C++ libraries they wrap.) The code itself mostly works but needs to be cleaned up a bit, documented and most of used and tested.

Now on to Marble. I was able to get an initial version of Python bindings for the Marble widget and related classes done and committed to subversion in time for the soft freeze. This means that we will support bindings for the marble widget in KDE 4.2. I'm pretty excited about this and the possibilities it can open up to people with crazy geo-data ideas who want a fast and effective way of implementing them. This also dove-tails nicely with my recent involvement with OpenStreetMap. OSM is a great way of combining cycling or a commute with geeky map making.

After the kdebindings meeting about a month ago in Berlin, I had a 8-ish hour long trip back on the train from Berlin to Nijmegen. Deutsche Bahn's trains are rather civilised and have power on board for all your laptop charging needs (provided you can get close enough to the seats with the tables *and* the power outlets). Anyway, after getting some preliminary Python coding working inside KDE 4's systemsettings (thanks go to rdale for his help), I had a go at trying to fix up the PyKDE class documentation to more closely match the C++ KDE API docs. About 5 weeks of hack time later I now have something which is ready enough for the public. The formatting is much more in line with the C++ docs and the pages are laid out and cross linked much better than the previous class reference for PyKDE. It is still not perfect (code fragments are not translated to Python), but it should be perfectly usable 98% of the time. Give it a try.

This is part of my effort to update the PyKDE docs a bit move them over to the KDE techbase where it is much easier for everyone to help keep them updated and to add more information.

Oh, and I can't forget the obligatory:

Thank $DEITY for feature freezes. It's only after the bulk of the KDE libraries are frozen that bindings people can come into action and franticly update everything before the RCs and the final release of a shiny new version of KDE. It's not much time and it only takes a last minute update to one of the C++ headers in the KDE break the bindings build. (That is the risk you run when you use almost every part of an API). But I can report that Python support is ready for 4.1. yippie! \o/

In the last month I've updated PyKDE4 for KDE 4.1. Incorporating all of the changes to the KDE libraries into the Python bindings and generally making sure that things are working. Jim Bublitz's tutorials, documentation and example code is also in the kdebindings module. In the process I've also created Python bindings for the DNSSD module, knewstuff, soprano, phonon (KDE's version), nepomuk and akonadi. There aren't many APIs in kdelibs and kdepimlibs which aren't covered with Python binding support. Incidentally, if you're a Python developer and you see an API somewhere in KDE which isn't covered but you would like to use, then get in touch and I'll see what I can do.

My next targets in Python bindings support are kcmodule / systemsettings modules, and other plugin mechanisms. I've got almost-ready-for-beta ports of my older utilities Guidedog (network connection sharing) and Guarddog (firewall). Ported to KDE 4 and Python, which should make they much easier for other people to hack on, not to mention debug. (I'll take an exception and a real stacktrace over a segfault any day.) And hopefully sooner instead of later I'll be able to make a start on a new version of Guidance administration tools for KDE 4.

Kross, the scripting framework, is one of the pillars new with KDE4. While the project started already a while back in 2004 it enveloped over the time to a rather big codebase. During the KDE4-process one of the main-goals was to decrease the codebase what can be even more difficult then writting new code.

Jim Bublitz has been industriously working on getting the Python bindings for KDE 4 into shape. Part of that work is documentation of course and for that Jim has put together a very handy documentation viewer which combines reference docs with code samples and example code all in one easy to navigate package. One of the classic documentation problems for GUIs which are as customisable as Qt/KDE, is that everyone can, and often does, have their own visual style configured for their desktop. This of course means that any screenshots accompanying documentation simply don't match what is in front of the user most of the time. Having real widgets displayed and operational in the reference docs themselves solves this problem for Python developers at least. I think it's real neat.

Some screenshots below: