(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:

Python language bindings for KDE's libraries, PyKDE4, has landed in KDE's subversion repository. Jim Bublitz has been working behind the behind the scenes on PyKDE4 for quite some time, and now PyKDE4 is stable enough to enter its new home in subversion. The last of big sweeping changes to the code, like licensing notices and module layout for example, have been done and PyKDE4 is in good shape for those who want to get in there, port their applications or create new ones and help shake any bugs out. Now that KDE's libraries are mostly settled, changes and improvements to the bindings will be incremental in nature and not too disruptive for Python developers.

Almost all classes in kdelibs are covered, except Phonon which is waiting on imporved namespace support in SIP before we can add support. Supporting tools like a Qt designer compiler that works with KDE classes and uses i18n() are also in the works, along with extra support for things like installation, handling i18n messages etc, and not to mention documentation and example code.

PyKDE4 is in KDE's subversion repository in /trunk/KDE/kdebindings/python/pykde4/ . Be sure to read the INSTALL and README files for more information. Thanks go to Jim Bublitz who has done the real heavy lifting here, and also to Phil Thompson who developes SIP and PyQt4 which PyKDE4 is built on top of.

In between porting some of my older KDE 3 C++ over to Python and Qt/KDE 4, and also fixing some bugs in Guidance, I've had a little play around with QtJambi. QtJambi is Trolltech's new bindings generator and bindings for using Qt4 on Java. Or to be more accurate I should say that the bindings are for the Java Virtual Machine, and not just for programs written in the Java language. One of the interesting features about VMs is that they don't have to be tied to a single programming language. You can run all sorts of different languages on the Java VM or the .NET / Mono VM. Now, one of the not just interesting, but really /cool/ features of VMs is you usually don't need huge slabs of binding code if you want one language to call code written in another, provide both languages are running on the VM itself. To put it simply: you can use QtJambi with a whole swag of different languages that run on the Java VM. Here is a little example of the Qt analog clock example written some other weird and wacky language: (anyone know which?)

So some money come my way and I finally caved in and bought myself a laptop, after having talked on and off about the idea to Deb for the last couple of years. I bought an Acer Aspire 5612, which is to say 15.4" widescreen, 1Gb ram, 120Gb HDD, Intel Duo Core with the matching set of Intel chips and Intel 945 graphics. All for about 850 euro. The price was right, the specs were right, and best of all is that the drivers for everything are good *and* FOSS. Being able to buy it off the shelf, literally, in a real shop, is also handy, especially if you are impatient. I've got Kubuntu Edgy running on it plus that other OS that came with it, (for Deb who wants it for her work).

This started as reply to Richard's post, but it got too big so I've supersized it.

You would think that Eric would know his computer industry history a little bit better. The transition from 32 bit to 64 bit won't resemble the past. Even Eric's account of the past doesn't resemble the past.

In this fairly long article I discuss my attempt to simplify file and device management in KDE, while avoiding some of the draw backs of the current media:/ io-slave.

The Challenge

About a year ago I expressed concern about all of the extra io-slaves that have appeared in KDE. The intention of the new slaves was very important (e.g. better file and media management) but the implementation could be better, IMO. The problem as I saw it is that wholesale replacing the unix file system heirachy with a new but incompatible heirachy (e.g. system:/) comes at a price which is too high. The user gets a usable heirachy for dealing with files, but this heirachy doesn't work in non-KDE applications. Give a system:/ URL to apache or gedit for example, and they will give you an error message.