Opportunity for intership at KDE e.V.

KDE e.V., the non-profit organization which represents, supports, and provides governance to KDE has grown significantly over the last couple of years. In 2008 we hired Claudia Rauch as part-time business manager taking care of event management, partner communication, and organizational support. Since beginning of 2009 she works full-time for us, and in August this year we opened a joint office with the Free Software Foundation Europe in Berlin, Germany's enthralling capital.

To continue this growth and being able to increase KDE e.V.'s support for the KDE community and free software, we are looking for an intern in the area of event management, business, and communication for the Berlin office. Read the full job description for details.

This internship is an exciting opportunity for passionate candidates to gain some experience with working in a high-performing non-profit organization on the topic of free software in general and KDE in particular. If you are interested in the position, please send your application to the board of KDE e.V.. If you know other people who might be interested, please point the to the job description as well.

openSUSE 11.2 and SUSE Studio

Last week we celebrated the release of openSUSE 11.2, the latest incarnation our fine green Linux distribution. It's a great release. People seem to like it. One quote: "OpenSuse stands out as a fine example of what a Linux desktop operating system can be."

Here at the SUSE Studio team we got quite some requests when openSUSE 11.2 will be available in SUSE Studio. Rest assured: We are working on it. There is some infrasructure to adapt, importing repositories, updating templates, upgrading Kiwi, and we are also planning to add a feature to migrate openSUSE 11.1 appliances to openSUSE 11.2, so you don't have to start from scratch, when you want to make use of the latest openSUSE for your existing appliances. It will need a little bit of time, but we'll add the support over the next few weeks.

So stay tuned, you'll soon be able to make use of all the openSUSE 11.2 goodness in SUSE Studio as well. I'm looking forward to what you will come up with.

4,273,291 lines of code

4,273,291 lines of code, that's the size of the KDE core modules, which are released as the official KDE software distribution, as of today, the numbers generated using David A. Wheeler's SLOCCount. Of course we all know about the problems with counting lines of code, but I still find it interesting to run these statistics from time to time. I was doing so tonight, and thought, when I do so, I can just as well share the data with the world.


Please see this as an interesting but not too significant data point about what's going in KDE, and don't forget that removing code is one of the finest tasks of a developer.

Of course these four million lines of code are only a part of all the KDE code that is written. There are tons of applications which are not part of the standard KDE distribution, but are just as great. Would be interesting to do the complete statistics, but this is hard. How to get hold of all KDE source code which exists?

Concluding random data point: SLOCCount thinks that it costs $ 175,364,716 to develop the code of the KDE core modules.

KDE Showcase

This week there is the openSUSE Conference in Nuremberg. There is a lot of activity planned, and as there will be quite some people there from both the KDE and openSUSE communities, I thought it would be a good idea to use that opportunity to work on a project I always wanted to spend some time on: Creating a KDE Showcase.

The idea is to create a live system, which shows KDE as it's meant to be. Based on openSUSE, but with plain upstream KDE packages, augmented with some demo data and configuration, this system can be used to show KDE at trade shows, be given to users as a teaser, provide a reference for press people looking at KDE, and lot of other cases, where you want to show KDE in all its glory.

A couple of years ago I made a screenshot for a contest showing KDE 3.1.5 in action:


This screenshot was a success, and won me a price., Now, five years later, I would like to do it again with current technology. Not only doing a screenshot, but a whole live system, and of course with the latest KDE 4.3.1.

We'll have a small team at the conference, which will work on creating KDE Showcase. If you would like to join the fun, there is a session on Thursday afternoon as part of the unconference. Or just contact me directly. Ideas and other input are more than welcome. We'll collect what we are doing at the KDE Showcase wiki page.

How to build a KDE 4.3 distro with SUSE Studio

Last week SUSE Studio was launched, and this week KDE 4.3 was released. They make a great combination. With SUSE Studio you can build a KDE 4.3 distro in just a few minutes. Here are the instructions how to do it.


SUSE Studio provides openSUSE 11.1 as a base template. By default it comes with KDE 4.1, but in the openSUSE Build Service, there are the latest KDE packages available. To build a distro using them, just follow these steps:

• Go to your home page in SUSE Studio, click the "create new appliance" button, select the openSUSE KDE 4 template, choose a fancy name and click the "create appliance" button. You'll end up in the appliance editor.
• Go to the software tab, click on "Add repositories", search for "KDE4", and then add the repository "KDE:KDE4:Factory:Desktop openSUSE_11.1".
• Go back to the software selection, and remove the pattern "kde4", and the package "kde4-kdm-branding-openSUSE".
• Search for "KDE 4.3", add add the pattern "KDE 4.3 Default Desktop".
• If you prefer the original KDE branding over the openSUSE branding, replace the packages whose names end with "branding-openSUSE" by those ending in "branding-upstream".
• Do whatever other modifications you would like to do (for example uploading a beautiful wallpaper, or select some of your favorite applications), go to the build tab, and click "Build".
• Wait a couple of minutes (could be slightly longer, if the system is very loaded), and you are done. You can download or testdrive your new KDE 4.3 distro now.

As an example I've build a live CD with KDE 4.3 and the original KDE branding. You can download it from the Studio site.

KDE SDK status after hackweek IV

My goal for the fourth openSUSE Hack Week was to create a KDE SDK. When I started I thought this was mostly a technical challenge. I coded, packaged, built appliances. But while doing all this I found something much more interesting. In this post I will tell the story, and where it lead me.

I will start with the end, the technical end, the resulting product. Here is a screenshot of the KDE SDK appliance, running in SUSE Studio test drive. It shows my variant of Qt Creator, running the KDE SDK plugin.


This is only a technology prototype. It's a real appliance, containing real packages, built from real code. But neither the quality of the code, nor the quality of the UI, is anywhere close to what I want it to be, and there are large gaps in functionality. But that's ok. The really interesting results are what I learned while creating all this.

It started a week before hack week. I had a lot of ideas what to do, but I wasn't sure what would be relevant for users, so I asked in my blog. The feedback I got in comments on the blog or via direct mail was pretty clear, the idea of the KDE SDK resonated with lots of people. So I decided to give it a go.

At the start of hack week, I took a couple of design decisions to give the project a clear direction. It made it easier for me to start, and it again gave me quite some feedback. Some people advised to use a different programming language or a different IDE, and there were also some good hints on how to do details. I will revisit the design decision in the light of the experience I made during hack week and the feedback I got, in a later blog post. For hack week they gave me a good start. Knowing how to approach the project, and having feedback on the approach, that helped me.


The first thing I implemented was a skeleton plugin for Qt Creator, to give Creator some KDE spin, and to provide a base for all the things I wanted to put on top of it. I cloned Creator on gitorious.org and hacked away. After making some progress, getting the plugin running, and taking a first screenshot, I ran into some problems, where I couldn't easily find a solution. The core plugin with the welcome screen was structured a bit confusingly, and due to the lack of documentation it was a bit hard to find out how to get to the current project data or how to add additional window panes in the IDE. Of course I had the source code, which helped a lot. But even more helpful was to go to the #qt-creator channel on IRC, and talk to the Creator developers directly. They were very friendly, and I thought, wow, free software is great. You not only get the software and its source, free to use, distribute and modify, but you also get access to the people working on the software, can discuss the code, and receive help to get into the code yourself. We might perceive this as a given sometimes, but it's actually a priceless feature.

Once the plugin was in place, I went on with creating KDE application templates for getting users started. At first I had planned to write my own template generator, but then I remembered a hint annma gave me in response to my initial blog about the KDE SDK. She recommended to use KAppTemplate to generate KDE application templates. KAppTemplate actually does that very well, so I decided to use it. I needed some tweaks, because I wanted to preselect the name and the working directory of the application to be generated, so I cloned it on gitorious.org, added what I needed, and packaged it in the openSUSE build service, ready to be used in my KDE SDK appliance.


At this point I started to think. What makes developing KDE applications great? Sure, there is exciting technology, there are great libraries, there is lots of existing source code, there are lots of places to find help. But the most important feature is the KDE community. All the feedback, advise, help, code to use, pragmatic tips, which I got for the KDE SDK project, all this came from the community. This made the difference. Interacting with other people with the same interest, sharing goals and culture, this made me much more productive than all the technology.

Encouraged by this insight I continued with one of the ideas I wanted to implement for the KDE SDK, the integration of online services, for tasks like source code hosting, package building, or publishing applications. Connecting to the online services promised to also give some better connection to the community. I decided to go for three services for a start, gitorious.org for source code hosting, the openSUSE Build Service for package building, and kde-apps.org for publishing application info. I invented a simple XML format collecting the meta information how to access these services for a given application, made Creator put this into the source code directory of the application under version control, and added support for it to the KDE SDK plugin in Creator.


But there was one technical problem. When Creator starts, it has no projects loaded, so I didn't have access to the meta information of an application. So what could I show to the user, until a project was loaded? As I had to test the implementation of the connection to kde-apps.org anyway, I decided that I would just load the list of friends from kde-apps.org and show it until the user had loaded a project.


When I saw the result, I realized that this was much more than just a test of loading some data from a web service. It actually was a useful feature. Some of the people on this list were the people I had to talk to in order to get my project done. I had to talk to Frank about the upload API for kde-apps.org, and Klaas was working on a library to access the build service from Creator. So having these people present in my development environment added a real value. Of course just listing them was just a start, but all of a sudden a whole bunch of additional features came to my mind. What if I showed their latest commits, the status of the packages they were building, or a direct contact to them on IRC, or their latest mails to the relevant developer's mailing lists? This would have been exactly the information I needed, and which I still had to collect the hard way now, by using a dozen of different tools and manually combining the info I needed. So again the connection to the community appeared as the major feature.

I did some more work on the plugin, added details panes for the different online services, improved the attica lib for accessing kde-apps a bit, and fixed some bugs in my code generation framework for XML, Kode. This was needed to deal with some of the XML data involved in communication and storage within the KDE SDK framework. Technically the following screenshot pretty much represents the state of what I have now:


This hack week brought me the interesting insight that the best feature of a KDE SDK is not of technical nature, but is the KDE community. This closes the circle. During the last hack week I worked on the social desktop. While the idea is very promising, it's hard to connect it to useful functionality for the general use case. But when focusing on a concrete case, such as developing KDE applications, everything falls into place. There is so much use for social interaction and integration of the community when doing KDE application development, that it's very easy to come up with ideas how to make use of it in an KDE SDK. Relating commits to friends, connecting to IRC handles, integrating mailing lists, see what others are doing in terms of coding, packaging, communication. Exchanging source code, documentation, help, hints, advise, interacting with users on application directories, and much more.

So in the end, the KDE SDK becomes developer's social desktop. This is a great result.

Will code for XML

When working on my hackweek project, the KDE SDK, I had to deal with some XML parsing for operating REST web services. To make this easier I made use of my old project to automatically generate XML parsing code from a
schema. Yesterday Tobias blogged about the new XML Schema features in Qt 4.6, and wrote about the need to generate code from schemas. Having this thought come up twice in only a few weeks can't be an accident. So I brushed up the Kode Home Page today, which has a solution for this problem.



Kode is a project to handle C++ code generation, especially in the context of XML parsing, with a special focus on web services. It's so important these days to be able to easily operate XML based web services, and handle all kind of other XML data conveniently, that we really need great support for this use case. In C++ this is usually relatively hard, mainly because of the static nature of the language, but with code generation this problem can be solved.

The tool which has developed over the last five years, admittedly with long periods of inactivity, is kxml_compiler. It can take an XML schema and generate C++ classes with a nice native Qt API which deal with representing the data and all the XML reading and writing stuff. This saves a lot of boring and annoying coding of trivial code.

When I started this project, I was convinced that an accurate and complete formal description was the key to this mechanism. Nowadays I'm not that convinced anymore. I found it much more practical to go for a 80% solution instead of striving for perfection. As result I implemented the support for using XML examples as a schema description. This makes it easy to just rip off examples from informal REST API documentations, or to use instances of an existing format, and let code be generated from that, which deals with this data. It works surprisingly well, and doesn't have a lot of overhead. Obviously it's lacking in some areas, and the implementation is still far from being production ready, but it is a useful tool and it solves the problem for quite some cases. It accommodates quite well for the needs of the rapidly changing world of Web 2.0 and its APIs.

The code lives in KDE playground. If you are interested in working on it let me know.