Home | About Me | Photos | Writing | Research | Scratchpad | Projects

Rapid Application Development in KDE

Ease of use has long been the holy grail of desktop development in Free Software, with interfaces and functionality becoming ever more accessible and usable as they become more sophisticated. Underlying the development of the most impressive desktop technologies has been a parallel development in ever more accessible and usable development technologies, and some have become so sophisticated that they now provide some of the most advanced rapid application development frameworks in the industry. This article will focus on such technologies in KDE, the popular desktop environment, and in particular, on PyKDE, Kommander and KJSEmbed.

Putting it in perspective

But first, I ought to explain why we should care about rapid application development. If one looks at KDE and GNOME, the two leading Free Software desktop environments, the first impression is that the vast majority of work is done with traditional technologies, namely C/C++ combined with a widget toolkit. But this appearance is deceptive, since it is not just through hard work that they have progressed so quickly, and allow very rapid application development, but also through clever architectural decisions. In a sense, KDE and GNOME could be thought of both as desktop environments and as development platforms.

Why is this important? Well, the first obvious benefit is that by providing a platform that is easy to develop for, you will get more done in a shorter space of time, and so the DEs progress very quickly, and of course more consistently. The second obvious benefit is that you can open up the development process to more people, since, for example, one needn't know how KDE handles file dialogues, nor how GNOME sets up its menus; a relatively complex program can simply plug together UI elements and provide some code to glue them together with appropriate functionality. But there is another aspect to this, which is that certain technologies facilitate development in ways that the original architects might not have envisioned.

I ought to note now that I am a KDE user and enthusiast, and so for the remainder of this article, I will focus only on KDE. I am quite aware that there are a lot of very interesting technologies in GNOME, so don't take this to be some kind of petty advocacy for one DE over another.

In KDE today, a user can rapidly develop new functionality without ever learning C++, or indeed without ever learning any programming language at all.


So now to the first technology, PyKDE, a set of Python bindings for KDE. Again, I chose PyKDE over RubyKDE or any other binding because of personal experience. Python is widely admired for being a simple but powerful object-orientated programming language, and is ideal for GUI development. To get an idea of the power of PyKDE, one only need look at its cousin, PyQt, and in particular at the feature rich Integrated Development Environment (IDE) eric3, developed entirely using PyQt. In terms of functionality, PyKDE offers more or less everything that 'C++ KDE' does.

Python is, compared to C++, extremely easy to learn and subsequently code with, and being object-orientated with reliable garbage collection and error tracebacks it allows the programmer to avoid a lot of the problems normally associated with programming. One can code the simplest of KDE applications in 11 lines, and this succinct style carries through to the most complex applications, significantly reducing the time and coding required to create something as complex as eric3.

But the benefits of PyKDE are to do with more than Python itself. KDE's architecture, based around KIOSlaves, KParts and DCOP, trivialise KDE application development as much as possible. A typical application will use standard KIOSlave methods to access files wherever they may be (e.g. on your hard drive, shared across Samba, on an audio CD, etc.), KParts to construct menus, editor frames, html frames, etc. and DCOP to communicate internally with other parts of the program, and externally with any other components in the KDE desktop. Each of these three technologies make much of developing a KDE application more akin to assembling flat-pack furniture than carefully crafting the whole cupboard yourself. So when you use PyKDE because you don't want the complexity of C++, you are also given extremely simplified methods to access all of the power of KDE's architecture, making an application that in the end appears to be extremely sophisticated.

KDE has taken basic object-orientated concepts of inheritance and reuse, and, thanks to language bindings like PyKDE, given the world complex functionality that is easy to implement.

But it gets better still. Designing an application's GUI can be a nightmare; once you try to piece together even a "OK/Cancel" dialogue from scratch, you begin to appreciate the difficulty of putting together something as complex as an e-mail client or an IDE. But thanks to Trolltech, the company that created Qt, budding KDE developers have Qt Designer, an application that lets you design GUIs graphically, point-and-click, rather like Visual Basic. You literally draw your GUI, dragging and dropping GUI elements onto the canvas, arranging them as you like, and then setting up the logic by which they will hook into your code. So you might, for example, add a button that will select a file to be worked on, and set it up to hook into some code that will open a KDE file dialogue. Using Qt Designer in conjunction with PyKDE, you find yourself essentially plumbing together the GUI with little snippets of code, and can code, for example, a respectable text editor in a day.

There is one final twist to this story. eric3, written in PyQt and constructed using Qt Designer, is itself now a useful technology in developing KDE applications. According to Phill Thompson, author of PyQt, "you can run eric3 and just start creating KDE classes, calling methods at the interactive shell. A method is executed as soon as you hit the return key - it make it very easy to explore KDE programming by just playing around."