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.

SUSE Studio Launch

Today we launched SUSE Studio as part of Novell's SUSE Appliance Program. This is an exciting event, as it marks a major milestone for the work we did in the Studio team for the last two years. With SUSE Studio you can build your own Linux, fast and easy. You only need a web browser. To achieve this, a lot of code was written, a lot of feedback from users was collected, and a lot of work was done to deliver a great user experience. At Linuxtag 2008 we presented Studio to the public for the first time, followed by an Alpha and a Beta period where we invited more and more users. We talked at FOSDEM and Linuxtag 2009 about Studio and presented the Studio Kiosk at various trade shows. All this comes together now in the launch of SUSE Studio as part of the SUSE appliance program. If you would like to give it a try yourself, sign up at susestudio.com, and we'll send you an invitation.



The major features of Studio, such as building appliances and testing them in the web browser, are pretty well known now, not least thanks to an amazing community, which has created walkthroughs, screencasts, reviews, and tutorials. But there are also some lesser known features, for example the API, testdrive networking, public download URLs, or the MySQL configuration. I'll try to find some time to write a bit more about these features later.

For my personal work Studio has become an important tool. I used it for example to create the Marble Live CD, or for my hackweek project, the KDE SDK. It's also a nice way to try out software or create an updated openSUSE version, for example with the latest KDE. But many other people are using Studio for interesting projects as well. Some of these are collected on the SUSE Studio appliances page in the openSUSE Wiki. If you have created something with Studio, please don't hesitate to add your project there.



One of the most interesting aspects of working on SUSE Studio is the technology side of things. It's a complex and demanding system, so it was an exciting challenge to actually build it. When we started as the SUSE incubation team, our mission was to explore new technology and foster innovation, and we learned a lot while applying this mission to the work on Studio. As a base we use Kiwi, the SUSE command line imaging tool, and we basically put it on Rails, with the web interface you can see on susestudio.com written in Ruby on Rails. Rails is a fantastic framework for doing web applications, and we use it not only for the UI itself, but also for internal HTTP APIs. SUSE Studio even made it to the list of amazing applications on the Rails web site. Another area where we learned a lot is deployment. It took us a while to find the right combination of procedures based on git, Webistrano, and system administration tools. But now we have a three-layered weekly release process, which works pretty well, and enables us to get fixes out to our users in a quick and reliable way.


All that said, from my personal point of view the best feature of SUSE Studio is the team which created it. It's an honor and a pleasure for me to work with people who bring together such an enormous amount of talent, experience, and passion. I really enjoyed the last two years, and I'm looking forward to a lot of other great stuff coming from this team. Guys, you rock.

Creating a KDE SDK

Last week I had written about my ideas for the fourth openSUSE Hackweek. I got quite some feedback and most people seem to think that the KDE SDK is the most useful idea. So I'm going to work on this for the hack week.

My goal is to create a software development kit for KDE, which makes it as easy as possible to write KDE applications. The main target audience are third party developers, who want to create desktop applications. The entry barrier should be as low as possible. There should no special knowledge about KDE, development processes on Linux, or familiarity with the community be required.

I thought a bit about how to best approach the creation of a KDE SDK. This lead me to the following design decisions:

• The SDK will be delivered as a sofware appliance. I'll probably make a VMware image and a live CD for a start. This makes it easy to use it everywhere, independent of operating system or other system constraints. It also makes it easy to set up a very well-defined environment for the SDK, so that all components play well together and don't interfere with other parts of an existing system.
  
• As a base for the appliance I'll use openSUSE, because this provides not only a great base system, but with the openSUSE Build Service and SUSE Studio it also provides excellent tools for creating and distributing appliances.
  
• The UI of the KDE SDK will be based on Qt Creator. The main reasons for this choice are that it provides a pretty clean and simple UI, and that it's easy to hack, as the code is pretty straightforward and it's conveniently hosted in git on gitorious.org.
• Application programming language will be C++. Some of the script languages might be easier to grasp, especially for beginners, but for KDE and Qt C++ really is the native language. Documentation, examples, and most code is in C++, so it's most easy to get help how to do things. It also avoids the complication of having the extra level of a language binding.
• Integrated documentation. There is lots of documentation floating around in various places. The SDK needs to integrate that in some way and provide pointers to what's relevant and helpful.
  
• Integration of online services. There are lots of online resources and services, for example documentation in Wikis and other web sites, mailing lists, IRC channels, web sites like kde-apps.org, or web services for development like gitorious, the openSUSE Build Service, or SUSE Studio. The SDK should integrate these as far as possible, so that the user gets the full benefit of all these community supported services. Maybe the SDK could even be basically stateless, so that all data is held online, and it doesn't matter with which instance of the SDK and from where you are using it.
  
• Full software life cycle support. Developing applications is not only about writing the code. The code has also to be packaged and deployed to the user. There is a rich infrastructure to do all that, so the SDK should make use of it and support stuff like creating packages of the application, and publishing them at the places, where they can be found and used by end users.
• Version control is essential. So the SDK will support git and gitorious.org out of the box. This should be done in an as transparent way as possible, which guides the user through a defined workflow, so the user gets the benefits of version control, but doesn't suffer from complexities of the underlying system.
  

I'm willing and plan to revisit every single of these decisions later, but to get started I will follow this path for now. For detailed progress updates about how the KDE SDK development goes see my hack week blog.

If you are interested in helping with creating a KDE SDK, let me know. I would be happy to team up with others to get this project done.