Interview with Aaron Seigo

A few weeks ago, Trolltech announced that it would be sponsoring the work of KDE developer Aaron Seigo full-time. Seigo has been working with the KDE project for some time, and is now working on the KDE Plasma project, a new direction in the way that users will work with the desktop. We asked Seigo if he'd spend a little time talking about the new project, and the direction of KDE, and he kindly obliged. Read on for an interesting look at what's going on with KDE.

LM: So, now your work is being sponsored?

Yeah, which is pretty exciting for me. A really great opportunity. I mean, usually when these kinds of things happen its often tied to, you know, the company wants this or that done and what Trolltech has done in this case is look for someone in the community that’s doing things that they go “well, this is really good,” and they want to support that.

Up until now, for the last four years or so, I’ve been working in and around the KDE community just on my own time, evenings, weekends and whatnot — holding down a day job, family and the whole thing at the same time, so it has gotten a little bit hectic in the past. It’s going to be an interesting future for me here on out, because it’s going to be what I do during the day.

LM: How did this come about, did they contact you and say “we want you to work on this?”

Yup. They contacted me, and said, “we like what you’re doing, we’ve got some budget set aside to do some community development and we’d like to point some of that budget your way.” So, we talked about how that work, and what it would look like. We talked about myself moving closer to where they are, say in Norway, but I’m just going to stay headquartered here in Calgary, Canada. There’s just so much to be done here in North America for KDE that it seemed like a good idea.

LM: Are they specifically saying “we want you to work on this,” or are they just saying “we like what you’ve been working on, keep doing it”?

A little bit of both, actually. I’ll probably be appearing here and there at technical conferences and doing some Trolltech-related presentations around their toolkit, but other than that, they saw what I was doing with the Plasma project, with the open source desktop workshops and my community involvement in general and they said, “look, can we make sure you have the ability to keep doing what you’re doing and even more of it?” So, it was a really nice fit. They were shopping for someone already doing what they want done. I’m not going to be sidetracked onto other projects, so it’s really nice. You can’t really ask for much more than that.

LM: What were you doing before Trolltech?

I was doing contract development… mostly Linux-based, which was nice, a conscious decision I made years ago — I want to work on open source environment even if I’m not creating open source technology in my day job. I want to be at least working with it, so I’ve been doing develoment in a variety of environments, from C, C++ right through to, I did some PHP work… almost exclusively in a Linux environment. That’s what I had been doing.

LM: How did you get into KDE specifically?

At the time, it was right around when 2.0 was in alpha and I was working for a company and picked to head up a development team in a start-up company right around 1999 and we were developing graphic distributed administration tools for UNIX and Linux, and of course the dot-com went pop, and the VC funding that was driving that evaporated, so I ended up with a few months at the end of 2000 and the beginning of 2001 where I just didn’t have anything to do. I didn’t want to get involved in another project right away. I wanted to kind of give myself a bit of a breather, collect my head and decide what to do.

I had been playing around with the 2.0 KDE development series, and we were working with the Q toolkit at the company as well, so I was already kind of familiar with that technology, and looking around at KDE and saying “wow, there’s a lot of promise here,” the technologies that they were bringing together were just unparalled in the open source world at the time. It was still very rough, things were crashing all the time, APIs were changing, sometimes daily, but you could see Kparts and dconf starting to take shape, and I had an immense amount of respect for what they were doing. So, not being able to stay completely away from computers, I got involved, submitting a patch here and there, I ended up writing a weekly summary of development events, I would track all the different KDE development e-mail lists and wrote a summary of what happened — much like the Subversion weekly report that happens right now, Derek Kite does that for the community. So I got into the community part of that, somehow I eventually ended up maintaining an application and next thing I knew, I was speaking at events here and there about KDE, somehow over the years I just got more and more into the project. It’s a wonderful group of people to work with, and astounding technology, it was just serendipity. I happened to have a few months, and that was all it took.

LM: What was the application you were maintaining before ?

The first application that I actually took maintainership of, I believe, was KSCD, the CD player in KDE. I maintained KJoss briefly, I looked after Kcontrol for a few months. For the past couple of releases I’ve been the maintainer of the panel, Kicker. Basically… I have this problem where I see something orphaned or not getting enough attention, I feel I have to run towards it and take care of it. Up until now, I haven’t actually brought a new application into KDE’s CVS or Subversion repository. I’ve been doing maintenance and keeping some of the tools that are there up-to-date and with less bugs, so I’ve gone through some of the administration tools as well, and sort of cleaned up some of the bugs, up till today, I’ve been sort of a maintenance programmer within the project.

LM: The world needs those too!

Yeah, well I mean, it’s funny. Software developers… creating something new is dramatically exciting. There’s no end of people who have ideas for new features or new applications, but oftentimes it’s harder, the trickier, more boring stuff that doesn’t always get addressed. Yeah, I’ve spent days sometimes looking for annoying, nasty little bugs. It’s not the sexiest work in the world, but it’s rewarding…

LM: Let’s talk a bit about Plasma. First of all, what the heck is it?

Alright. Well, up till now I’ve been largely kind of a maintenance programmer within KDE. I’ve introduced a few features here and there, and tidied things up and worked on usability, but with KDE 4 coming up, and I’ve been maintaining Kicker for a few releases, one of the things we’ve done for the 3.5 release of Kicker is introduced a number of new features and nice work. Some eye-candy, some actual usability features such as the new “Add Applet” dialog. So with KDE 4 coming up, I kind of looked at it and went “you know what, I feel like it’s time that I… did something special for KDE 4. The combination of KDesktop, the panel… have been pretty static over the lifetime of KDE 2 and KDE 3, not a whole lot of revolutionary things have happened there, so I started looking around and I realized that ever since the Mac was introduced in the mid-80′s, ’84, the desktop has been a place to put icons. Period.

But back when the Mac first came out, you’d have a floppy disk to put in, it’d have a dozen or two files on it, maybe, so you didn’t need a whole lot of real estate number one. The number of files and the kind of files you were dealing with was pretty basic. It made sense in 1984 and through much of the 80′s, for that matter. But, if you fast forward to today, we’ve got instant messaging, we’ve got groupware, we’re much more task-oriented, project-oriented when we work on our computers. We also deal with tens of thousands of files. It’s not unusual to go to the average user’s PC and find that they’ve collected several thousand of files, be it music or pictures off their camera or whatnot.

In a corporate environment, even more astounding in the amount of data you see being collected. So, the way we use our computer and what we use them for has changed dramatically. The desktop is still there to collect icons, and you really can’t fit more than a couple of dozen icons on there before it becomes just a mess, an icon zoo. So I started thinking, “what if we actually used the desktop for something useful, what would that look like? What could we use it for?” And I looked at the Panel, and said, “you know what, it’s funny, the desktop panel and the desktop itself, they live in their own little worlds. So, really, they’re two static pieces. When you first log in, you see the panel, you see the desktop. In the users’s mind they definitely syncopate, we see people often file bugs against the KDE Panel when it should be against the desktop, or vice-versa, so in the user’s mind they’re really one piece.

So, I wondered what we could do to bring those two pieces in line? We also have things like SuperKaramba, Konfabulator, Mac OS X Dashboards where Widgets, mini-applications, are becoming more in vogue, people find a lot of use in them. So I started playing with all these ideas and putting them together and out of that came Plasma, the concept that if we take the KDE Panel and the desktop and then the idea of miniature applications like you see with SuperKaramba, and then fuse them into one application and use that as an actual enabler for how we use the desktop which is for collaboration and project-based type work, maybe we have something that is the next step forward.

Figure 1. KDE – An example of an extender being used by Plasma when a USB device is plugged in.

Personally, I don’t know about you, but I often have two or three projects I’m working on in a day… when I’m working on project A, I need different things than when I’m working on project B. If I’m uploading files to the website for a family album, I need different tools than when I’m working on KDE, but my desktop doesn’t actually reflect that, currently. So that’s where Plasma’s going.

We also sat back and went, “you know it’d be really nice if we could really show what X, the X modern protocol, especially from X.org, is capable of these days. Cause it’s got a bad reputation or has a crude one largely because development was so stagnant for so many years, but X.org has really picked up again and we’re starting to see some exciting capabilities on the X.11 platform. We also have Qt 4 coming out from Trolltech, that’s got, I was playing around with the new painting facilities that were there yesterday, and was really happy with how much more progressed Qt 4 is over Qt 3 for what we can do eye-candy wise.

So there is on the one hand this emphasis with Plasma to enable workflow, then on the other hand let’s also do it in a way that when people get in and use it, their jaws are just kind of perpetually open. That’s the goal.

Figure 2. KDE – Examples of work with taskbars and extensions with a desktop “basket.”

LM: What state is Plasma in right now?

Well, we’ve taken the, we’re starting with the desktop Panel and Kicker, and we ported most of that to Qt 4 right now and we’re in the process of disassembling the various libraries that exist right now and reforming them around what we’re trying to aim for with Plasma. I’m not a huge believer in “let’s just re-write everything from the ground up, from scratch.” I find that when you do that, you end up not only duplicating a lot of effort, but introducing a lot of bugs and removing a lot of learned lessons in the code. So we’re starting from a known place and moving it towards where we want to be. The end result, code-wise, will probably look very little like what we started with, but we are starting with the current code base.

We ported that to Qt 4, it’s running, it’s working. Still some hitches here and there, but that’s essentially together and we’re working on the beginnings of the actual Plasma libraries.

Figure 3. KDE – An example of stackable / tearable extenders.

LM: What about, from a usability standpoint, is this mostly being driven by what you think the desktop should look like? A lot of times developers think what’s appropriate for a desktop may not be what users think it should be.

That’s been traditionally one of the things that people often bring out when they talk about the open source desktop in a negative way. They often say “well, it’s for developers, by developers.” And one of the things we did and continue to do with Plasma is, we actually didn’t start with code. What we did is started with artists and some usability people. We’ve got a great working relationship in KDE right now with OpenUsability.org which is a group of usability experts, primarily over in Europe, that is spending a lot of their time working with us on open source-related projects. So we started there, with people doing visual concepts and designs with usability people and I spent a lot of time speaking with average users, and not the average user as defined as the people who log onto IRC and chat with us there. I actually took a laptop one evening and went to a local pub/restaurant where it’s pretty open and people chat about things and took it down there and ran people through concepts. I really wanted to understand, you know, what do people use their desktop for, realizing that I’m a power-user, not your typical user. I definitely ought to serve me well… I don’t believe in the myth that if you create something that’s well-accepted by the masses that it’s going to be useless for the power user. I don’t think that’s a necessity. But, yea, with Plasma we started with a human-centric approach, if you will and we’re forming the code and design principles around that. Otherwise, we’d just be presenting something different, not necessarily better.

LM: What’s the time-frame that we’re looking at for KDE 4 and Plasma?

KDE 4 itself, we haven’t done a formal plan as far as timing goes. We’ve got aKademy 2005 happening, which is the KDE world conference, at the end of this month in Málaga, Spain. So we’re going to be doing a lot of that, sit down coordinate, what our time targets for KDE4. It looks like, though, if I were going to guess based on discussions I’ve had and gut feeling, I’d say near the end of 2006, fall or winter 2006. It’s a bigger jump than from KDE 2 to KDE 3, but not as big a jump as from KDE 1 to KDE 2 from a development and code perspective. It’s not as long as KDE 2 development cycle, which was years, we’re not looking at a multi-year development cycle. It’s going to be longer than our usual 9 to 12 months cycle.

With Plasma we’ve actually knocked out a much more refined set of milestones. If you go to the Plasma website we’ve got the roadmap on there. We’ve finished the Qt porting, by this month we’ll have a lot of libraries that existed pulled apart and put back together in, generally, the way I want to. There’s going to be a huge amount of work that happens at the end of this month in Málaga. In September, we’re actually going to start doing the bindings, where we actually start developing some of the new applets that will be using some of the libraries that we’re creating. Which is also one of the exciting things that is happening, is one issues we have on Linux, and the open source desktop in general whether it’s BSD or Linux, is being able to distribute software. We don’t have a stable ABI where I can say “here I compiled this on SUSE 9.3, run it on your OpenSolaris box.” What we’re doing with Plasma, is we’ve got the base libraries in a compiled language, C++. But we’re going to be providing bindings for a number of different languages. JavaScript or ECMAScript, number one, for a variety of reasons. Number one is that we want to keep the barrier to entry really low. So that if you can put together a Web page and do a little scripting, you can create a widget on your desktop. That’s very similar to the approach that Apple took and I think it made a lot of sense.

We’re also going to be providing bindings for Ruby, Python and Java. We’ve got people lined up who have actually committed to doing the bindings for each of those languages. And then, the nice thing about that, is that we’re going to be able to distribute improvements and new applets and capabilities across the board whether you’re using SUSE Linux or Red Hat Linux version whatever or OpenSolaris, or BSD or Mac OS or whatever. We’ll actually be able to have one package that a person can create and with a single click you install it and it’s running. We’re trying to do an end run around the problem of creating and sharing new widgets. Which is one of the reasons right now, Kicker, everything has to be written in C++. So we’ve got a fair number of applets for it, but nowhere near what it could be. It’s partly a distribution problem, and partly because so many people now like writing in Ruby, or Python or a language like ECMAScript. So that’s a new approach as well that we’re taking.

The clock is a great example. We’re shipping with two clock faces, an analog one and a plain text one and that’s it. If you want more, well, you’ll be able to go into the configuration and say “get new clock faces.” We’ve already got “Get hot new stuff in KDE,” where we can actually distribute new sets of configuration data or new additions to software over the network, just point and click, where it does all the installation and that for you, it already exists. So we’re going to be leveraging that, so you can say “okay, well I’d like some funky new clock that is a binary clock or pulses at me wildly.” So you go to “Get new clock faces,” it shows you a screenshot of each one. Say “okay that one,” and you’re good to go. It will allow us to ship a default lean setup, and at the same time, offer people a lot more choices. If you think about it, that’s actually what Firefox did, with their extensions. It allowed them to ship a very simple browser that did browsing, and we want to ship a panel that does what you need a panel to do, at the same time that happens to be easily extensible… we’re going to be able to offer over-the-network seamless additions.

LM: I’m glad you brought up Firefox. It sounds like a great thing to have, but once you have this easily-distributable extensions-type architecture, doesn’t that bring a whole new problem from a security perspective?

Um, it can. It depends on how you do it. It’s kind of like running with scissors. I mean, scissors are a great tool. If you run around with them pointed at your eyeballs and trip a lot, it’s not a good idea. And the way certain companies have dealt with scriptability and extensibility in the past, has been a lot like running with scissors. So, the question is, “can you use scissors without jabbing yourself in the face all the time?” And I think the answer is yes. If you look at languages like Ruby for instance, it allows us to sandbox it at the user level. Java has done this for a long time as well. With the ECMASCript system we’ll be using, the next generation of KJSEmbed, which is the KDE JavaScript engine, which is also used in WebCore by Apple… we can actually do sandboxing as well. So we can keep applets in their little space, that’s very important. Number one, it’s not going to be “you can run anything you want, any way you want.” There’s going to be a defined API that covers what you can do, you can paint to their space, you can write to their configuration file and that’s it. Number two, it’s not going to be a peer to peer system, where a person can throw something un-audited onto the network… the items that we’ll actually push out over the “Get hot new stuff” network will all be vetted by us internally. So, it’s not an open upload, download. Those two combinations of things, where we control the distribution to the automatic retrieval is important, and secondly we are showing that sandboxing is critical. That was one of the early design issues that we addressed… I don’t think it’s a problem, if done right.

That’s one of the things I love about this community, not just the KDE community, but the open source community in general. We’ve become a community that is acutely aware of the need for security and it’s really nice because it’s starting to ripple out elsewhere. Look at Microsoft and their attention to security — whether or not they’re doing a good job of it is another question — but, they are at least recognizing that it’s important, and they realized it’s important because we realized it’s important and we’re doing a good job and people are looking at us and saying “hey, if they can do it, why can’t the rest of the industry?” So, yeah, I don’t think I could get away without being burned at the stake if I brought Plasma and it was easily used to hijack your system or your desktop and we’ve got a few hundred brilliant minds that look at every commit that we make.

LM: When you named off the languages that would have bindings, I didn’t hear Perl in the list.

No, you didn’t. I’ll come right out and say it and probably get flamed for it, I can just see my inbox piling up already. No, we don’t have bindings for Perl. I actually did a programming stint in the 90′s where I did tens of thousands of lines of Perl for an application which is back when Perl 5 was just emerging. I think it’s a great language for what it’s designed for. Larry Wall set out to design a language to process text and, wow, great job. And it expanded onto the Web and it was, slightly less good at that, but it did a great job there too. When it comes to object-oriented GUI design, I think we’ve got far better tools at our disposal these days, namely Python, Java, Ruby, etc. I don’t think that Perl is a tremendously great fit for these kinds of events.

But that’s just me. If someone steps up and says, “hey, I’m going to write the Perl Plasma plugin, then [that's fine]. The only bindings that will be loaded and available by default is the JavaScript ones, the others will all be in plugins that get loaded on demand. so if you don’t run any Python applications you’re not going to incur the overhead of a Python runtime. If you say “I want to run this applet,” a Python one, then the Python plugin gets sucked in automatically.

So, someone can easily step up and say, “I really love Perl, I want to write a billion things in Perl,” they can write set of bindings for Perl, distribute the plugin and there you go. Which is another nice thing about the open source world, is if you get somebody who says “I don’t like Perl,” and that’s just stupid and silly, it can be fixable by someone else says “well, that’s silly and here’s the fix for it.”

LM: What about backwards-compatibility, once this makes the break from the traditional KDE Kicker and Panel, what happens to the applications? When you make the break from KDE 3 to KDE 4, will there be a need to rewrite applications?

Not rewrite. There’s been a number of changes in the Q Toolkit, we’ve got a number of changes in the KDE libraries as well, most of them look to be vast improvements. So, that what means for application developers, most applications, so far in our experience — we’ve ported KDElibs, KDEbase, admin, games other bits and pieces of KDE over and the porting is actually pretty straightforward and pretty simple. Trolltech’s done a great job of providing a set of Qt 3 backwards compatibility classes. They’re actually called Qt 3-whatever. So if you use the old tree view, just use Qt 3 tree view in your code and recompile it and that will work.

At the same time, if you want to take advantage of all Qt 4′s capabilities, you’ll have to tweak things a bit…. even then it doesn’t seem to be a huge amount of effort, depending on your application. That’s from an application developer’s standpoint.

From a user’s standpoint, in some ways even more important, what kind of pain will they incur? Fortunately, the way KDE is designed and installed, you can install two different versions in parallel… We’re aware of these issues and we’re working on them as we go along. So, knock on wood, with enough dilligence on our part and enough user testing, we’ll actually be able to have a KDE 4 that rolls out if you have an application that was written for KDE 3 and hasn’t been ported yet, that’s okay. You can run it in a KDE 4 environment and it runs and works proper.

One other kind of perspective, with Plasma, are we going to radically change the desktop? No, we’re not going to radically change it. We can’t afford to radically change it. My goal is not to create something I’m proud of from an academic perspective or theoretical perspective, it’s something that’s actually better for the user. Which, in some way, means that if you come from KDE 3 or come from Windows or Mac or some other platform, you’re not going to be completely lost. You’re still going to be able to put icons on the desktop if that’s what you want to do.

Comments are closed.