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.
