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.

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.

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: