Thursday, August 6, 2009

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.

Monday, August 3, 2009

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 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, 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, for source code hosting, the openSUSE Build Service for package building, and 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 anyway, I decided that I would just load the list of friends from 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, 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.

Saturday, August 1, 2009

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.

Team Profile

What makes a great team? One important factor is that you have a balanced set of skills and personalities in the team. A team which only con...