Monday, July 20, 2009

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
  • 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, 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 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.


  1. Great intiative, but I would urge you to consider including the PyQt alternative. The main reason is mentioned by you and besides there are quite a few non-beginner python hackers out there.
    I think there are quite a few tutorials out there and they may just need some restructuring and updating. I am quite new to python and KDE myself, but would be happy to lend a hand if you decide to include the possibility.

  2. As Snirp said, please please please don't lock us Python people out - I've learned Py just to code apps in Qt (well PyGame too) and would hate to be left out. I'd also like to lend any help I can if you include PyQt.

  3. Well, first make the Python case with the QtCreator guys. Then it shouldn't be a problem including Python.

  4. @Tom
    As I see it, Qt is currently not interested in adding python themselves. There may be some 3rd-party efforts underway to develop a python plugin (
    It is inevitable to arrive at some stage, but not worthwile to hold up development of the "KDE SDK". Guess we will have to make do with C++ for now.

  5. I wonder why you are not suggesting to use KDevelop as the main UI. As this is a KDE SDK and not a Qt SDK I would expect that the project specific tool is choosen.

    I use the new version in for my daily work and my opinion is that this is the best C++-IDE available for Linux.

  6. Great! It's a pity that you can't install it to /opt/kde-sdk-1.0, but it's a nice project indeed that will solidify the offer.

    I think at a KDE-SDK made up of "kdelibs" (splitted in sub-libs) + other High Quality libs + KDE Creator (customized version of QtCreator).

    Release 1.0 should be stable, not necessarily complete ;-) [the less features, the less crashes!]

    See this mockups for the KDE Creator side of the equation (if any):

  7. Do you intend to include building for windows support?

  8. Please considere including KAppTemplate frol kdesdk which provides a GUI wizard to generate templates to start programming easily. This is a light application but very useful! The templates can also be used in KDevelop by the way.
    Not sure abuot QtCreator and cmake: is cmake well integrated in QtCreator?

  9. This is a great idea! Looking forward to the results!

  10. You talk about using gitorious... so is the target audience writing an open source app?

  11. @Ian: Remember that Qt Software also started out using Gitorious internally. Gitorious !=

  12. @annma: using kapptemplate (or its templates at least) for Qt Creator is something I was planning to look into.

  13. @Snirp: Python certainly is a good option for application development. To keep things simple I had to make a choice, though, and C++ just is the most mainstream solution in Qt and KDE land. But as I said I'm willing to revisit this question later.

    @Christoph_Bartoschek: Qt Creator is simpler than KDevelop, that fits my goal to keep things simple very well. It also seems to be more stable than KDevelop 4. Part of this project will be to make Qt Creator more KDEish, so that it shouldn't make a big difference.

    @maninalift: Windows support would be great, but is currently out of my scope.

    @annma: I'm a regular user of kapptemplate, so I certainly will consider it for creating application templates. cmake support in Qt Creator exists. Still have to see how good it is.

    @Ian_Monroe: Good question. I think one of my unconscious design decisions is to target free software development. Shouldn't be difficult to adapt it to proprietary development.

  14. Hi,

    Why only to focus on application developers alone? Why not some new guy who want to contribute small bug fixes? Actually new development is easy as there are no dependency. To make bugfixes, the user has to check-out source code, compile, resolve dependency etc. This is where a pre-build SDK would come handy.

  15. I'm not so sure if creating a SDK as a Live-CD or VMware image is such a good idea.Sure it probably will suite some use cases but I think it is not flexible enough, at least not from my point of view. Maybe I missed something/Don't follow your lead.. But what if:

    1. I want to create a app based on kdelibs where I also want to include some other lib not included on the cd/image?

  16. 2. I want to use my specially configured editor/dev tools tha I normally use?

  17. thuswa: Just installed those packages in the VM. It's easier to set up one editor than setting up the whole KDE development environment. I think the idea is great.

    Cornelius: Will it include SVN snapshots of all parts of KDE, so you can just SVN up and develop against head of e.g. kdegames?

  18. @HPC: Thanks. I missed the point that the image obviously wouldn't be read-only. Sorry...

  19. its a good idea..and i hope finally it will break the entry barrier for people like me..

  20. Is Qt Creator ready for such usage? It doesn't have even directories hierarchy support yet.

  21. After seeing this:

    I have to say KDESDK should have KDevelop. It just has better features to get into KDE development and it showcases the power of KDE much better. Very sad Qtcreator was picked.


Freedom and Fairness on the Web

There is an ongoing debate about freedom and fairness on the web. I'm coming from the free and open source software community. From this...