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.

A small status report about the Python bindings and support in the almost arrived, KDE 4.3. All of the APIs have been updated of course and I've added support for polkit-qt. This makes it possible to write applications and configuration tools which feature the much needed (and working) "Administrator" button.

Yes, I'm down here in Gran Canaria with the rest of the geeks. It's shorts and T-shirt weather 24/7, even when it is cloudy and "bad" like it is now. (Actually this is better. The full on sun is a bit too much.) There are a lot of old familiar faces around and a lot of new ones. Speaking of which if you are at GCDS and are working with Python on KDE then please come and find me and introduce yourself. (I'm the geeky one with glasses with the Kubuntu T-shirt on.) I'm curious to know what you are developing, what is working well in Python bindings, what is not and what you would like to see in the future. Help me help you.

I'm about 18 months behind the curve here compared to you trend-setters in KDE-land, but I think I now actually "get" git. Meaning that I now have a mental model of git which makes sense and I can use to make sense of the numerous "Git $X seconds" blog posts hanging around on the web (where the number $X is always smaller than the last blogger). I remember sebas having a go at explaining it to me and me not understanding what the big deal was or what it really was about.

The thing that did it was Tom Preston-Werner's "The Git Parable". Just a 10 minute read and boom! there it was in one go in my head: clarity. I seem to understand complex things better when I understand the forces that shaped them into their present form. I like "why"s with my "how"s.

If you're familiar with CVS / Subversion style revision control systems, then you are doomed to failure if you try to learn git in terms of SVN. I've tried that and failed. It is best to clear your mind of that model and read Tom's parable. Even the name of the git command "rebase" actually makes sense after reading Tom's piece and this post by James Bowes.

I'm now browsing through the Git Community Book, it's pretty straight forward. If I'm feeling really confident I might carefully try out git-svn on part of KDE's SVN.

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.

(Warning, rant ahead)

There has been a lot of excitement on the web about Google's new browser Chrome. So much excitement that it has been spilling over into the free desktop blog world. Excitement is good in general, but I think many people are missing the point of Chrome and what Google is trying to achieve here. Chrome is not about building a better browser or winning the browser wars. It's about building a better platform for running web applications. It's about winning the internet operating system war. It's about determining what the "operating system" for running internet applications will look like in the future. It's about platforms, APIs and VMs, not web pages.

This is Google's way of trying to lift the base level of the web application platform out of the year 2001 and into the modern era. What's so special about the year 2001 you ask? That's the year when Internet Explorer 6 came out. The browser which still represents 36% of the page hits in the year 2008 according to the thecounter.com. IE6 also represents the last passable effort by Microsoft to improve their browser as a platform for developing applications which run inside it. For those who are too young to remember, once Microsoft won the first browser war just after the turn of the century and crushed Netscape, they threw the brakes on the development of their browser completely, and from what I can tell, cryogenically froze the IE development team for the next 5 years. Don't believe me, go check the IE release dates yourself, google the dates too if you don't trust Wikipedia. Microsoft woke up to the fact that the browser was an emerging platform that threatened the their windows platform. (I'm not sure if woke up is the right word, Marc Andreesen of Netscape Communications pretty much blurted out the whole plan when he commented in 1997 that the web browser would reduce the operating system to an "unimportant collection of slightly buggy device drivers".) From a web developer point of view nothing interesting has happened in IE since at least 2001.

Chrome is Google's way of lifting the base platform that web developers can reasonably target for their applications and expect users to have installed. Google need this in order to be able to create the next generation of their applications like Google Docs, Google Maps, Gmail etc etc. Right now they are held hostage by Microsoft. What is important is not so much that people run Chrome, but that the performance improvements and new APIs make it to the browser users themselves, whether that be through Chrome or through improvements to other browsers like Firefox and Safari etc. A web browser is just a useful way, or a Trojan horse if you like, for getting the platform out to the masses. That's the plan.

Some more comments I want to make, or "Signs that you've missed the point":

• "You complain that simple pages will use more memory." -- So what, we've got plenty of memory to run as many simple pages as we want, it is the big pages (read: applications) which are the problem.
• "You complain that Chrome doesn't have better RSS support or a built in RSS reader." -- The idea is this. You go online and find an online RSS reader. You then go to the little 'page icon' menu and select "make shortcut" and place an icon on your desktop. You then click on the icon and Chrome opens up without the unneeded browser address bar and controls. That's now your RSS reader.
• "You don't like the idea of the 'web application' mode where the browser controls and address bar hidden." -- Web applications are only web pages in technical sense, not a conceptual sense. You don't need those old browser controls any more than you need a hex memory viewer when using a desktop application. The URL is an implementation detail, get over it.

So take your time, and think about these points, and save yourself from missing the point and posting rubbish about Chrome on your otherwise excellent blog or website. Thanks for listening.

(Ok, the web developer hat is coming off and the KDE hacking hat is going back on. Time to get back to hacking on Python support in Plasma. \o/ yay )

Just a small announcement. Development version 1.1 of my little network routing configuration utility is up on my website for your testing pleasure. There is no new functionality. I've just ported it from KDE 3 and C++ to KDE4 and Python, saving it from ravages of bit-rot. It's a neat little utility and it would be a shame to let it get lost on the migration to KDE 4. It is also in Python now which should make the code a lot more accessible for contributors. If you've written a few shell scripts in the past, then your skills a probably high enough to hack on Guidedog and fix any bugs which show up.

My attention is spread across too many projects these days which slows down fixes and applying patches. So I've now put the guidedog source in KDE's subversion repository in the playground/network section. (/trunk/playground/network/guidedog/) This will hopefully take me out of the critical path for fixes and patches.

I've also got a mostly done port of Guarddog to KDE 4 and Python here too on my computer which I want to move into KDE's SVN one of these days.