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.