I have moved my blog to kdedevelopers.org. The previous blog was self-hosted (at home) but I simply don't have enough bandwidth to host it (that box will be used to serve uber-lightweight static pages and a koji instance only).

And since I've been mostly blogging about Qt and KDE in the past, I think that this is the best place to host my blog.

See ya!

Just in case anyone is following me on kdedevelopers.org, I moved my blog to http://blogs.fsfe.org/gladhorn.

I finally decided to move my blog. kdedevelopers.org has served me well, but now I want some more features. Blogger provides some killer features, such as using my own domain, blogging by email, or the powerful comment system. So from now on you'll find my blog at blog.cornelius-schumacher.de. See you there.

Today is the first day of my employment at a wonderful company called KO GmbH. KO GmbH provides services around software dealing with office documents, notably KOffice. I'm excited to have found such an inspiring job working in Free Software.

At the KOffice 2009 Sprint in Berlin last June, I got to meet many of the KOffice developers and was impressed by the productive atmosphere. In my job at KO, I'd like to help KOffice become enterprise-ready, by which I mean, that I want help the KOffice team make a reliable and flexible office suite.

My role in the company is software architect. The business cards Tobias Hintze, our CEO, sent me just say 'architect'. That inspired me to spend some time on this first workday to pose for a picture that goes well with a dEUS song about Buckminster Fuller, the architect after whom the buckyball was named.

Listen to 'The Architect'.

Disclaimer: I have no desire to re-ignite KHTML vs WebKit arguments. Rather, the purpose of this blog post is to hopefully enlighten a technical question.

Over the last few months I've heard many KDE developers in various forums bemoan the lack of a working and stable WebKit KPart. The motivation behind this complaint seems to be that KDE folk want a WebKit browser option for KDE. Thus the naive solution is to just get the WebKit KDE KPart in shape. Given this motivation... the solution is wrong IMO.

I can speak from some experience here. I've been working on QtWebKit for quite awhile and have also worked - in the past - on the WebKit KPart plus Konqueror integration that Simon started. For a time, it was building and running just fine. You could install it and change a configuration file and Konqueror would render using QtWebKit. However, the integration was *far* from complete. Plumbing the sources of Konqueror I learned a nasty secret: Konqueror is highly KHTML API specific. Konqueror has deep integration with KHTML that goes far above and beyond the KPart API. Creating a QtWebKit KPart is woefully insufficient for the purpose of providing anything more than a basic HTML viewer.

A simple HTML viewer is no where close to a fully modern desktop browser.

This all makes sense if you stop to think about the history of Konqueror. Konqueror is a generic desktop shell. It is designed to allow basic viewing of various documents in various formats. Of course, it has become much, much, more than that. And the key to this growth of features is Konqueror's steady adoption of API's above and beyond the generic KPart API.

Which brings me to my point: if parts of the KDE community truly want a modern browser based on QtWebKit they'd best be looking at solutions beyond Konqueror. Otherwise you are left with two hacky solutions: make a QtWebKit KPart that is API compatible with KHTMLPart OR migrate Konqueror source to make it less dependent on KHTMLPart. The former is not going to be fun as the KHTMLPart API is not refined or polished and highly KHTML specific. The latter can only be accomplished with a lot of work set aside for refactoring or through nasty '#ifdef KHTML callThisWay() #else callThatWay();'

Both of these solutions are sub-optimal in my opinion.

Two days of KDE Wiki Meeting are over. Danimo, Frank, Lydia, Dominik, Milian, Thorsten and me met in Berlin with the goal to get some more structure into the KDE Wikis and provide a plan for the future, where to put content. I'm happy to say that we accomplished this mission.

While we have TechBase for high quality technical documentation for a while, and the corresponding UserBase for end-user information since last year's Akademy, we were still missing a proper place for community content, especially for content which is mostly community internal, of more transient
nature, or just not finished yet. The idea to create a dedicated Wiki for this community content was floating around since a while, and now we created it at community.kde.org.

To make it clear which content belongs where, we created a mission statement, which gives clear guidance about which Wiki serves which purpose. You'll find it at wiki.kde.org in a few days. The basic idea is that userbase.kde.org provides end-user information, techbase.kde.org contains high-quality technical content for third party developers, distributors, and system administrators, while community.kde.org acts as a collaboration space for the community.

Actually community.kde.org already existed. It contained the charter of the community working group. But to keep things short and to the point we decided against creating another base, but go with the logical and short community.kde.org domain. The charter of the CWG will find a new home on the KDE e.V. web site.

With the creation of community.kde.org we can also shut down at least two places where community content ended up due to lack of a proper home. We'll shut down the old Wiki, which was available under wiki.kde.org, but whose content wasn't that well maintained, and which didn't fit too well in KDE's infrastructure because of technical reasons. We'll also move all the pages which piled up under the Projects directory on techbase, but in almost all cases didn't really belong there and also didn't match the quality requirements of being polished content targeted at technical people who aren't necessarily familiar with the community. Most of these pages find a proper home on community.kde.org, though.

In addition to the general cleanup and structuring we also worked on some improvements of the existing Mediawiki installation. Danimo replaced the OpenID login UI by a much more usable version, Milian finally managed to get rid of the annoying horizontal scrollbars inside the page on code samples, and we also discussed some more improvements, like the intensified use of templates and the introduction of a way to rate and classify documents on the Wiki to indicate their quality and make it more obvious what needs more work.

As a side track, we had an interesting discussion with some Tiki developers. They have an amazingly powerful and feature rich system, which would
be able to solve some of the problems, we still have with our Wikis, such as translation infrastructure. For now we decided for the sake of consistency and simplicity to stay with the current Mediawiki installation, but maybe Tiki is an option in the future.

Working on the Wikis was fun and satisfying because we got some concrete results, which will simplify maintaining KDE web content in the future. But besides all the work we also didn't forget to relax with a great dinner at a Chinese restaurant at Berlin-Adlershof, enjoying a great buffet, including cheese cake for dessert.

Thanks go to the KDE e.V. and Qt Software for supporting the meeting.

Tutorials Day rocked and logs are now available for those who missed it. Talks covered Ruby, Amarok Scripting, Artwork, Packaging and Kubuntu Karmic.

KDE needs as an entire project to support a Web browser that everyone can use in 2009. That's the simple message behind this blog entry and my talk at LinuxTag on Saturday.

If you need any more motivation to go out there and make that happen, read on.

If you look at for example kde-apps.org or kde-look.org, there are numbers of various KDE applications, utilities, styles, decorations and what not. Various contributors post there their work for others to try and use. This is the place where new software or other contributions often look for their first users.

However, if you look closer, you may notice one problem - most of them are only provided as the source tarball, with no, few or old binary packages. Sadly, here the old jokes about how difficult it is to install software on Linux are still valid - it is not difficult to find applications with comments along the lines of "I tried to compile it, it said <whatever error>, what do I need to do, help". The difference between providing or not providing a simple way to install your newest creation can be the difference between users using it or not.

This may not seem to be that simple to solve though. There are probably only very few people who have all the major KDE distributions installed, let alone actually know how to create packages for all of them and have the time to do that. There are other community members who sometimes provide binary packages, but those only do it for a selected range, and they have to update them as new versions are released. More lucky contributions get picked up and packaged by distributions, but that can be difficult for new ones, since simply they are new and not many users know about them. So it looks like the usual kde-apps/kde-look/whatever contributor needs to depend also on luck to actually even reach the potential users.

Well, for those who still don't know it, let me introduce you: KDE contributors, meet the openSUSE build service; openSUSE build service, this big bunch of people are KDE contributors.

The openSUSE build service is a tool that is used to build the openSUSE distribution, but it can be also used to build additional software for openSUSE (such as the additional KDE repositories that provide various KDE versions). And, what many people might not know, it can be also used to build software for other distributions.

In fact, I've been looking into the possibilities recently, and, in the process of it, I have packaged a bunch of random kde-apps/kde-look stuff in my home repository. And, right now, I have packages for various openSUSE versions and SLED 11, Fedora 10, Fedora 11, Mandriva 2009, Mandriva 2009.1 Spring, Kubuntu 8.10 and Kubuntu 9.04. There are some more distributions supported, for example Debian, but those do not yet have a stable release containing KDE4, so tough luck there.

And I tried to cover various possibilities of what gets posted on kde-apps/kde-look:

• I was probably the first one to package the KWin Aurorae SVG decoration engine by Martin Graesslin soon after he had announced it there, as soon as the necessary KDE4.3 beta2 release entered the KDE4:UNSTABLE repository. I also packaged the Nitrogen KWin decoration, just to have a decoration that builds on more distributions.
• I packaged a set of the Glassified KDM, Plasma and splashscreen themes. The themes were actually just tarballs containing the files (and that actually gave me a hard time when trying to package that for Ubuntu) that need to be uncompressed into the right place, but still, there is the convenience of just installing a package and be done with it.
• I miss the ability switch using keyboard shortcuts between taskbar entries like it was possible with Kicker. There was feature freeze, so instead of providing a patch for Plasma I went for a temporary solution and wrote a simple KDED module hacks that does it. And from the moment I uploaded it to kde-apps as TaskbarSwitch there were also binaries.
• I packaged KShutdown, Ksshaskpass and Kvkbd as examples of various applications. Together with Ksshaskpass I also created a local modification of the openSSH package and sent a request to its maintainer to include a change that enables openSSH to use Ksshaskpass. Kvkbd needed a patch fixing it to work with the XDM/KDM setup on openSUSE.

And the best part about it is that it was actually quite simple and easy. I just took a template for .rpm and .deb packaging, filled it in, tweaked a bit if needed and submitted to the buildservice. Then checked the results after a while, fixed problems and now it is all in home:llunak:kde, ready to be used. Anybody who can code a small KDE application shouldn't have a problem to do the same and then say that the package is in the repository home:<whoever> and that the installation instructions are at http://en.opensuse.org/KDE/Build_Service.

Of course, it was simple and easy for the Lubos Lunak who wanted to package those things, as that was the point. The other Lubos Lunak, the one trying to ensure it was that way, had it a bit harder. The openSUSE Wiki has a lot of information, but it was necessary to read it and try it out. Some work was needed for building from one .spec file for all RPM distributions (really just one .spec, the only package that needed conditionals was Ksshaskpass, and only because I knew the special handling needed to fit with openSUSE's openSSH). It is of course possible to build for each distribution using their .spec syntax, but I wanted the possibility of having just one syntax that would be mapped automatically as necessary using macros and package renames. Some work was (and still is) needed to help making .deb packaging as shared with .rpm packaging as possible (I think I can forget generating it automatically from the .spec, but for example Debian/Kubuntu build system accepts only .tar.gz tarballs, so there is a build service patch from me pending to make the possible conversion automatic).

That work is going to be only mine, though, the plan is still to make it easy for you. Well, ok, I wouldn't mind if at least somebody added better details to the distribution-specific pages linked from the main page, because I e.g. haven't managed to find out how to easily add a new custom repository on other distributions. So if you are waiting now for a howto, this will need to wait for a while, until it is prepared and cleaned up. You can however try to bribe me at Akademy into demoing it personally .

See you in the IRC channel in a few hours for interesting tutorials on a range of topics.