Ikhaya: And if you think back to the times when you first had the idea of replacing the old Kicker: how many of your initial goals have been accomplished?

Kicker in KDE 3

Aaron: That's a hard question to answer because the initial goals were so small and tame compared to where we've ended up. I wasn't originally thinking about smart phones or media centers, or the ability to send live widgets zipping across the network between machines .. but that's what we've achieved. When it comes to allowing people build work flows, we're providing that with Activities; my goals for visual beauty have certainly been exceeded; the possibilities provided for an integrated widget system have similarly blown past my hopes.

We still have a lot more work to do, but that's mostly because the ideas we started with have opened up so many new doors and avenues for us to explore. We're not finished yet, by any means, but I'm very satisfied with the idea that first set of goals have been met.

Ikhaya: As we are a support channel we know that there are still some problems. Where do you see the biggest problems in KDE that have to be streamlined?

Aaron: Some of the challenges we face are not directly in our (KDE's) hands. We face a lot of issues with changes in the underlying infrastructure; the advent of PulseAudio was horrifically disruptive to many of our users, for instance. There are also a lot of ongoing quality issues we face, such as the state of x.org and its drivers. While these are all improving, they often do so at a pace that isn't as quick as we might like. That's probably true no matter how fast they improve, though, since that's how we as humans tend to work.

But perhaps the biggest thing that needs attention is useful documentation. Userbase (http://userbase.kde.org) is a relatively new effort to open up the act of writing documentation to the broadest possible audience by using a wiki. It also emphasizes „how to..." type documentation over clinical descriptions of menu entries, for instance. Getting more people writing and contributing to that wiki will benefit all users of KDE software.

After documentation, we still have a lot of work to do when it comes to the social/semantic desktop. It's new technology not just for us, but also in general: no other software product meant for use on end-user systems has ever attempted what we're doing with Nepomuk, Strigi, etc. So we're inventing new solutions to new problems as we go and learning a lot in the process. We probably still have a few years ahead of us before we really are taking full advantage of it.

Kontact is also only now emerging in its fully updated version, using the new groupware system (Akonadi) and integrating with the rest of the platform. This effort has been years in the coming and has been extremely non-trivial to achieve, but the results are finally coming through. In the next few months we'll see the first major new release and with it improvements in performance and reliability.

There is also lots to do in the Plasma workspaces as well, including things like improvements to the desktop effects infrastructure provided by KWin and standardizing the effects across window managers, both of which are happening. Improvements to Plasma Activities are ongoing and the new workspaces are coming along nicely, as well.

Lots to do ... and that means all kinds of opportunities for those who would like to get involved in some way. The barrier to entry is very, very low and includes all kinds of useful tasks from writing documentation on the wiki to bug triage to contributing even the smallest of patches via reviewboard.kde.org that improves things.

Ikhaya: Is there a feature from which you thought "this will never work" and then get surprised to the contrary?

Aaron: Philisophical aside: I try to stay away from "nevers". I've seen enough things that should have been "impossible" happen over the years to be wary of that mode of thinking. Instead, I try to look at the risks and the benefits and guage how worthwhile it is to invest in such a thing .. but enough philosophy:

One feature set that really blew away my original assessment of it was the OpenGL driven desktop effects. It's non-trivial to do well, there aren't a lot of hackers drifting about who are great at OpenGL and at the time Compiz really had that niche cornered in Free software. We couldn't use Compiz, however, due to issues of stability, integration and the requirement to run in non-OpenGL environments, so despite the risks and daunting efforts, we had little choice to take it on. The results have been phenomenal, and these days Compiz and KWin developers routinely take inspiration from each other, and the effects offered by KWin are top notch. Many parts of the "environment window dressing" in Plasma Desktop, such as the full-screen widget dashboard or panel pop-outs, have benefited greatly from these effects.

Perhaps the biggest surprise, however, has been the success of moving beyond the desktop form factor to tablet, netbook and smartphone. Most people I spoke to in the mobile arena, even in Free software, were highly sceptical that we could make that leap successfully. We'd have to rewrite our entire stack, some asserted. Others said that our user interfaces would need to be redesigned from the ground up. We chose to look at it in a newer way: as a device spectrum ranging from small screens with touch based interaction on up to workspaces with mice and keyboards. This is similar to how the Linux kernel developers chose to look at computers as a spectrum from embedded systems to supercomputers.

With Plasma, we literally use the same code and many of the same UI components directly on all of these devices. That was supposed to be impossible, according to some, but we felt it was doable. How well it worked surprised all of us, though, I think. That the weather widget on my desktop works awesomely as a full screen weather app, or that the microblog desktop widget is perfect as a smartphone Twitter app .. the quality of that transition exceeded our expectations.

For things like Marble, KOffice and Kontact, the division between user interface and logic has paid off hugely as well. Each of those projects has been able to repurpose huge investments in logic, but also large parts of the UI as well (the map in Marble, the canvas in KOffice and the calendar view in Kontact). Again, this wasn't supposed to work so well.

Ikhaya: What are the prefered ways to contribute? Where is help needed?

Aaron: The preferred way to contribute is openly and with joy. As for areas you can get involved, they are numerous and include: promotion, testing, bug triage, documentation writing, distribution liaison, system administration (we have a fairly large amount of infrastructure these days!), artwork and, of course, software development. They all need attention, and we have nice communities of people around each topic. Pick what suits your skills and interests the most and dive on in.

You can find us on irc.freenode.net in #kde-devel as well on the KDE mailing lists (http://www.kde.org/support/mailinglists/) and lots of helpful people on forum.kde.org as well.

Ikhaya: How good is the quality of user-submitted bugreports?

Screenshot Dr. Konqi

Aaron: It's pretty good and improving all the time. The improved crash reporting tool ("Dr. Konqi") in KDE Platform 4 is helping immensley by helping the reporter create much better reports. It can even download the debug symbols packages for you, install them, then regenerate the backtrace with more details .. all with one push of a button. It also looks for (and often finds) duplicate entries already in bugs.kde.org. So we've worked hard on the tools, and we're matching that with working with our user community on how to improve input and interaction on bugs.kde.org.

Ikhaya: What are the most common mistakes?

Aaron: Getting angry at a developer you can't see because something failed. It's understandable to get frustrated when something doesn't work, but there are real people giving their work away for free(-as-in-beer) on the other side of that bug report. Too often people start out aggressive and fill a report with lots of .. well .. ranting. It doesn't help anything, and in fact lowers the odds that the report gets handled well. It even demotivates developers, some of whom have left in the past due to this issue. Our community's expectations and agreements on this case be found here:

http://www.kde.org/code-of-conduct/

Besides social accidents, the next most common mistake is not including enough useful information. A clear set of steps to reproduce the problem is pure gold for a developer; screen shots often say what a thosand words could never communicate; full backtraces in the case of a crash is almost always enlightening. See here for more pointers:

http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports

Ikhaya: Which is your favorite application in KDE?

Aaron: Oh wow .. having to choose just one is quite literally impossible for me. I love too many of them for different reasons.

Ikhaya: Is there a cooperation with Canonical and if so, how well does it work?

Aaron: There is. We've done technical previews of Plasma Netbook, for instance, with the Kubuntu team, and then continued to collaborate on the Kubuntu Netbook experience. App indicators are a result of working together as well, with Canonical adoption the Status Notifiers spec from KDE and building upon that in Gtk and GNOME applications. Canonical has also contributed back improvements to that technology, such as DBusMenu. Not only has this improved both KDE and GNOME software individually, but they work so much better together whent it comes to desktop shell integration.

There are, as always, improvements yet to be made and new efficiencies to be found, but we're on the right track in my opinion with good communication, collaboration and fair treatment going on.

Ikhaya: You held a keynote at this years KDE developer conference Akademy in Tampere, Finland and we heard some buzz about 'elegance'. Could you please explain what 'elegangce' mean?

Aaron: Elegance is the attribute of being unusually effective and simple. It embodies a design sensibility as well as a level of usefulness into one concept. It's not enough to just be straight-forward or simple: it also has to be useful or effective. It's not enough to just be useful: it also has to be streamlined.

Elegance comes in many forms and is broadly applicable to all acts of creation and design, and so I chose to emphasize it for the KDE community in my keynote. We can apply it to our application development APIs as well as to our user interfaces, so it's quite a universal concept. It's also a key concept because it can be approached with iterative improvements and has a huge impact on the enjoyability of a product.

I believe that KDE software has a huge set of opportunities in the "Elegence department" ahead of it. Removing more jargon from our user interfaces, streamlining the configuration interfaces even further, finding new places to implement implicit metadata capture for the social/semantic desktop system ... these are all small things in and of themselves, perhaps, but they require a global attention to detail and implementation and combined are able to take KDE software to a whole new level.

A lot of the recent developments in KDE have been driven by the idea of elegance, I just figured it was time we were open and conscious about it.

You'll be hearing more about this in the coming weeks as we are building some support systems for the pursuit of elegance in KDE.

Ikhaya: JavaScript stepped into Plasma. How well is it accepted?

Aaron: There are a couple of places that Javascript and the Plasma Desktop intersect. One is the Plasma Shell Scripting:

http://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting

This is used by many of our downstream distributions and deployers to easily manage and control Plasma Desktop and Plasma Netbook presentation. Kubuntu is using it, for example, to define the default layout of the Plasma Desktop shell.

Another important area Javascript is playing in Plasma is in creating new Plasma widgets, or Plasmoids:

http://techbase.kde.org/index.php?title=Development/Tutorials/Plasma#Plasma_Programming_with_JavaScript

This has opened up development of fun, cool and useful new apps to a whole new audience. Personally, I find developing these kinds of things in Javascript far quicker and more rewarding.

Several tutorial examples can also be found in the KDE Examples module:

http://websvn.kde.org/trunk/KDE/kdeexamples/plasma/javascript/

Other places Javascript has entered included things like animations, and we're getting good traction out of it there, too.

Ikhaya: Name three words that you associate with KDE

Aaron: Freedom, fun and friends.

I know for many KDE users out there it's just about software on their machine and is a fairly "cold" set of concepts, and that's fine. But for us who pour our creative energies and parts of our souls into it, it has become much more than that. It's hard to imagine something more rewarding.

Kudos to martingr for contributing screenshots and helping translate this interview.