file dialog jam session

Celeste organized a little usability jam session on #kde-usability this morning for the file dialog layout. Gwenview's Aurelien and Benno Dielmann also showed up to take part along with Celeste and I. I noted from the start that I didn't have time for a massive redesign of the whole dialog, just to keep the ideas from getting wild and therefore unachievable with the time I have for this between now and 4.2's hard freeze.

The conversation flowed basically like this:

• point out a target area to improve
  
• enumerate possibilities
• settle on which ones to try
• have Aaron code it, screenshot it, upload it
• have Celeste and the others examine the results
  
• rinse, repeat

During the meeting, which lasted just under an hour and a half, we did this procedure eleven times. Which is more iterations that I expected given that we weren't working with mockups but actually moving code about, compiling, etc.

The eleventh iteration didn't result in a code/upload step, it's my TODO for next time I spend an hour of time on this: put the same label on the places sidebar as we see in Dolphin to make it obvious that this is synchronized across KDE apps (Dolphin, Gwenview, Kickoff ..)

Once I find time to do that, then we'll schedule another lovefest on irc and subject unwitting victims innocent users to the results for testing.

If you'd like to see what the process looked like visually (which probably doesn't make as much sense as it would with the discussion that went with it) ... here you go:

• First Iteration


• Second Iteration


• Third Iteration


• Fourth Iteration


• Fith Iteration


• Sixth Iteration


• Seventh Iteration


• Eighth Iteration


• Ninth Iteration


• Tenth Iteration

As you can see, iteration 10 is still missing the Places label but we now have a spot for a search edit in the tools area at the top while having lots of space for the location bar. The nice grid alignment is maintained in most places, but I do need to change from using a KToolBar to just a regular QWidget with a regular layout on the top as well. You may notice in some of the shots that we looked at the results using different widget styles and dialog sizes as well.

(Before readers start complaining about the encoding widget, that's from KatePart which I use for testing since it is fast to start up and adds more widgets to the dialog, giving us a sort of worst-case scenario that also exercises more features of KFileDialog. The default dialog obviously does not have an encoding drop down.)

While this isn't a finished product at the moment, I thought some of you might find it at least interesting to see the development process we (developer, artist and usability specialists) go through together.

Or maybe this is a really boring topic and I just find it interesting because it's what I do with my life. ;)

file dialog layout

Not that you could tell from my blog, but I do hack on things other than Plasma as well. ;) It seems that once or twice a year I end up spending some time on the file dialog, and it's apparently that time of year again.

Right now the All Powerful KDE File Dialog has a few unfortunate usability, visual and functionality quirks that diminish it's wonderfulness. (Is that even a word?) I didn't feel like doing anything too major to it as it's a proven model; that and I don't want to spend too much time on it either given all the other things I've got on the go. But still ... It needs a bit of love right now.

After fiddling with it a bit, I dropped an email to the usability list. Discussion ensued, and Peter Penz provided some data he gathered from user testing he'd done with it. (It's very nice how the number of people working on file management stuff has really grown with KDE 4.) I continued fiddling with things trying to improve the visual layout and make the order of things more correct (e.g. for scanning). Here is what it currently looks like on my disk:



I'll leave it as an exercise to the reader to see if you can spot all the modifications. I'm not quite done yet, but it's coming along nicely I think.

As a historical note, here's what the dialog used to look like a long time ago:



We're obviously not quite so obsessed with frames and divider lines anymore, but a lot has remained at least somewhat similar as the dialog has grown in power and usability over the years.

p.s. The QtWebkit crash I mentioned in a blog a couple days ago has now been fixed upstream. Huzzah! I can browse without crashes now. =P

KTorrent + Plasma = Good Times

I just found out today that KTorrent ships with a DataEngine and Plasmoid. (Yes, sometimes I'm a bit slow. ;) Now I can watch my torrents progress without having to keep popping up the KTorrent window. Nice!

This inspired me to do a little bit of hacking on the applet this evening. When the icon is clicked, it now pops up the KTorrent window and if you drop an entry from KTorrent to the desktop KTorrent plasmoid is created.

Since KTorrent already has drag and drop support internally, all I had to do to get plasmoid creation working was add one line to the plasma-applet-ktorrent.desktop file: X-Plasma-DropMimeTypes=application/x-ktorrent-drag-object. Extra nice!

It took 17 lines of code, however, to have the plasmoid set itself to the dropped plasmoid. There's obviously room for improvement there in the Plasma API. Possible improvements might include a way to get at the drop data as text (would have eliminated 4 lines) and a way to query an engine for a sorce based on some data (QStringList DataEngine::sourcesMatching(const QString &key, const QVariant &value) would have eliminated another 6 lines). Those two additions would take those 17 lines of code and turn them into just 7.

It remains to be seen if these methods would have general purpose use outside of this one plasmoid, though. There's no point in expanding the Plasma API just for the KTorrent plasmoid ;) so it's an important question.

Finding and activating the window for KTorrent took only 8 lines of code, thanks to libtaskmanager and KWindowSystem. If this becomes a common thing for plasmoids to do we will probably want to provide a convenience function in libplasma for this to make it easy for plasmoids and to avoid having to bind all of a libtaskmanager for scripted plasmoids.

It also occurred to me that it would be cool to support dropping a torrent file to the desktop and having a KTorrent download plasmoid offered as an option. I haven't implemented this, but it would be easy enough to do with a Plasma::Service that encapsulated aspects of the KTorrent D-Bus service (which is rather comprehensive and well designed in my opinion). That way the plasmoid could just do engine("ktorrent")->serviceForSource("core") and use that to load the file. In fact, this approach could be used to provide interaction such as start/stop/pause as well.

And all of this because I found a cute new toy to enjoy but wanted it to be drag and drop aware. ;)

plasma-mid

My current areas of interest for 4.2 for plasma can generally be lumped into the following categories:

• Context: exporting the current activity and location to both plasmoids as well as other applications via Nepomuk (in progress; Nepomuk people were much more excited about this than I expected, usually I'm the excited one ;)
• Services: continuation of the JOLIE integration which I've blogged about in the past, as well as tieing in service announcement, discovery and user negotiation.
  
• Scripting: getting scripting to where it really needs to be; this is mostly being shouldered by the bindings crew, but I have some heavy lifting in the security and management areas
• UI smoothing: big target is the Add Widgets dialog which is due for a major overhaul
• MIDs, or mobile internet devices (yes, such as, but not limited to, the N Series devices)

This is, of course, in addition to the usual suspects like the wallpapers and panel hiding and new engines and widgets and ... and ... and ... thankfully the rest of the Plasma team seems to be as (hyper-)active as I often am. ;)

For the MID we've created a new Plasma "shell". If you're using KDE4, you're already using one such shell: the Plasma desktop workspace. A shell is simply a bunch of windows arranged in a way to provide access to all the goodies on the Plasma scene. The desktop shell provides desktop layers, panels, dashboards, panel configuration, etc.

The MID shell is much simpler than the desktop shell, since it is meant for devices with a far less chaotic life; you don't, for instance, often hook up multiple monitors at different resolutions to a MID. ;) It currently weighs in at just over 500 lines of code and provides a control area and a view area. It took me all of my Sunday and part of my Monday hacking time to put together.

This is just the beginning, of course. At Akademy we had a number of conversations culminating in a chalkboard frenzy on the last day about what we wanted to do with Plasma on MIDs. We will need to write one or two new wigdets, but several of the widgets we are able to pull directly from the existing code base. In fact, some of the work on the MID target will be also to the benefit of the stuff you see on your desktop.

As we make progress in turning our ideas born at Akademy (and which we continue to discuss on the mailing list) into code, I'll post updates here. We've got some cool ideas to put into place, and the whole idea of having a system tuned for a MID but which works with my laptop out of the box excites me. Being able to share code between the desktop shell, plasma-mid and other projects like Ivan's embedded system is also really tantalizing.

You can run plasma-mid from svn in a normal desktop session right now, even without a scratchbox or other special dev environment. For actual deployment and interaction testing, putting it on a device is obviously the way to go though. ;)

kwin ftw

Since I'm a little obsessed these days with software design that is adaptive, flexible and sturdy, it was with interest I read Lubos "Seli" Lunak's recent blog where he said:

"KWin's design is still about the same like in KDE2.0, and, apparently, it still just works. I can't see a problem with not having been designed from the group up for compositing, something that nobody even thought about at that time, yet getting there when the time comes"

That is really impressive as imeans that the code has the property of being able to go the distance by being easily extended and reworked without having to toss the whole lot.

What was really great to read in that same blog entry was that Seli has optimized KWin's performance and that it should now generally be on par with Compiz. Very, very nice.

We should keep in mind, however, that this is only half the battle: the effects themselves also need to be both performant and well tuned. The tuning aspect is actually more to do with the human perception than the CPU cycles in this case: non-linear animations (Sebastian, along with others, have done a lot of work in this area for KWin effects), animation timings (often shorter is better), functionality (I've given up on having time to go back to the coverflow switcher myself and implement mouse interaction =/ ) and little details like alignments and consistency are the other half of the battle.

That is why people like Lucas Murray and the other KWin effects hackers are my heroes for the week.

Permanent kudos to Seli, though, for ensuring that KWin can continue to rock on in the free world.

p.s. I heard not so long ago that KWin was originally pronounced like "Quin" rather than "Kay Win"; that is such a nicer sounding name! Perhaps we should spell it Kwin instead? =)

p.p.s. Coverflow switcher mouse interaction would rock, e.g. hovering a window could show it's title in a properly angled bubble above it, clicking on a window would select that window, etc..

p.p.p.s. nVidia's latest beta drivers seem to address the performance issues people were seeing with KDE 4.1 apps like plasma.

p.p.p.p.s. I've noticed that Seli has been blogging a lot more often this year, which is awesome. Is there a causal link between working on visual coolness and blogging? Hmmm...

weekend updates

Thought I'd offer a few updates from the weekend, which I've taken pretty easily just because I can. =)

Applet Positioning on the Desktop

Ambroz has been working on a new QGraphicsLayout class for use in full screen containments that basically acts like an organized corral: when new widgets are added, it tries to find a place for them that doesn't overlap with other widgets and if you drag a widget out of the containment or screen by accident, it pulls it back in. It resolves several issues at once, such as being able to drag items out of the screen with the applet handle, size changes leaving widgets in outer space and being left with piles of widgets in one corner after double clicking a bunch of entries in the Add Widgets dialog.

This work was the result of a build of things on Ambroz' part. I first started noticing his patches in bugzilla, but soon he was on the Plasma list and got his own svn account so I wouldn't have to commit his patches for him anymore. He fixed a number of smaller, but certainly annoying, bugs and eventually moved to the full screen layout issue. The first iteration of the fix was to write something just for DefaultDesktop; the second was to take this logic and make a proper QGraphicsLayout from it; the remaining step will be to eventually move this layout into libplasma where any Containement can make use of it.

The Beat Goes On

Lots of other work has been going on as well. Marco's been working on the panel control bar to make it more discoverable (in terms of its usability) and polishing up some of the widgets he recently added to libplasma (nice scrollbars and the tab widget), while Alex went on a absolute tear this weekend closing numerous bugs in both the 4.1 and 4.2 branches; I think he made over 20 commits on Saturday alone. Very impressive. Marijn has remained busy making sure we don't break compilation on the ARM architecture, usually due to one of us not using qreal as often as we should. Petri's continued to work away on containment switching so that it will work smoothly in 4.2.

In part, this is what keeps me going day after day without much pause: if I stop for too long I fall behind all the work everyone else is putting into things, and I can't have that. =)

More On My Webkit KPart Experience

I'm writing this with post with Konqueror, which may not seem very odd except that I'm using the "Compose" tab in Blogger. That's the one with the fancy HTML editting bits and it actually works! There are a few little bugs here and there, but in general: success. This is why I'm excited about QtWebkit usage: it gives me access to features I can otherwise only get in Gecko, and even a few that I can't.

There are still some problems in the KPart and QtWebkit though. The version that will ship with Qt 4.5 should be a lot more performant and have a lot of bugs worked out. Right now with Qt 4.4.1 when I close a tab before the page is completed loading, Konqi crashes. If it wasn't for the crash recovery feature in Konq this would have driven me back to the default khtmlpart some time ago.

... right now I think I'm going to go sit outside on my porch stairs and play some guitar in the sunshine.

FLA for KDE .. WEE!

In case you missed it, the membership of KDE e.V. have adopted a new legal instrument: a Fiduciary License Agreement. You can read more about it on theDot and Linux Weekly News.

So ... what does it mean?

Well, the FLA, or Fiduciary License Agreement, allows a contributor to grant rights to KDE e.V. over their contributions to the project. The extent of what is covered is defined by the signatory in the agreement and the whole thing is very carefully put together to keep KDE e.V. from doing Bad Things(tm) such as taking the code proprietary or from the contributor losing all rights to all work they ever do.

This will allow KDE e.V. to act on behalf of contributors if necessary, for example when we need to relicense code and the contributor can't be found (the GPLv3-compatibility relicensing effort from this last year is a good example of such a scenario) or if (heaven forbid) we ever end up in court over a licensing violation. These kinds of actions can only be taken by a person or entity that has the legal right to do so, and the FLA grants those rights to KDE e.V.

Nobody is required to sign an FLA, of course, and signing an FLA will never be a precondition to contributing to KDE in any way. This is strictly an opt-in service provided by KDE e.V. for those who wish to avail themselves of it.

The FLA has been the result of over a year's effort, mostly on the part of Adriaan "The Wookie" de Groot and Shane of the FSFE, our patient and diligent liaison in these matters who also attended Akademy this year (and took part in a really interesting panel session, to boot). We have the Free Software Foundation Europe to thank in large part for the FLA. Not only did we base our FLA off of theirs, we utilized the Legal Eagles (as we like to refer to their team of legal experts) extensively to refine and explain the document.

Of course, it all came down to the KDE e.V. membership who, at this year's general assembly gave the FLA their overwhelming approval in a vote taken on whether to adopt this legal instrument or not.

There are a couple of i's to dot and t's to cross, but then the documents will be available on the KDE e.V. website. As soon as that happens, I'll be signing a copy myself so that no matter what happens to me, my code or KDE there will be a way to manage the legal details of my contributions.

panel authohide

So today I sat down and went to work on panel autohiding. Short story: you can now hide your panels. Feel free to do a little dance, make a little love. You know the drill.

Longer story:

In KDE3 kicker had two really annoying attributes when it came to panel hiding: it polled for the mouse cursor and it actually moved the whole top level window around on screen. "So what?" you say.

Well, the polling meant that whenever a panel was autohidden, kicker would wake up 10 times a second and ask the window system, "Hey, where's the cursor now?" If it was along any edge or corner, it would emit a signal that hidden panels would be listening to. Not only was this mildly inefficient just due to the polling and what not, it meant that when kicker wasn't on your screen it was (ironically) waking up your CPU a lot. Not great for power consumption, but hey, at least it was all the way off the screen right?

Moving the actual window around was a problem because moving a window isn't exactly cheap. It's less expensive than resizing the window, though: that involves allocating a new buffer for the new size of the window, blitting the contents into that and then freeing the old buffer. So instead of resizing, kicker moved the window. Not perfect, but reasonably efficient enough that it works even on low end systems. All is great .. until you put more than one screen on your computer and a panel "in between" them. Then when the window moved off of one screen (pretending to hide) it would just move onto the other one. Whoops!

So I took a completely different approach with Plasma. Now we move the contents inside the panel window to animate hiding, which means it works even on multiscreen systems, and we use something called an "input only window" to trigger the unhide. An input only window doesn't paint anything to screen, but does let us get input events. When a panel hides, we create a teeny tiny little input only window and when we get an enter event, pop goes the panel. Voila, no more polling and therefore no more waking up the CPU ten times a second.

Now the bad news:

If you don't have a compositing window manager you don't get any animations. The panel just appears and disappears. This is because to do the move-the-contents trick and make it look convincing, the panel window background needs to be transparent and we have a policy in Plasma: no stupid tricks like fake transparency. If you want bling, you need to use the right tools.

I also haven't done the configuration UI for this feature yet, but it'll be there soon so those of you using KDE from trunk don't need to fiddle with your configuration files.

There's also a problem I've run into with some "interesting" optimizations that QAbstractScrollArea makes in painting that results in some white-blink. I may have to make some minor alterations to get it to work exactly the way I want.

I also haven't implemented "prevent hiding when a menu or something else like that is showing". So if you pop up, say, the kickoff menu the panel will hide when you go over it. It's not a big deal, and I'll fix this tomorrow along with some of the other rough edges.

Oh, I also implemented the windows-can-cover-the-panel option. Ta-da.

Microsoft and Novell reaffirm pact.

Microsoft has dropped another ton or three of cash on Novell and in celebration they issued a joint press release announcing this new phase of their relationship. I was never a fan of the original deal, feeling that it violated the spirit if not the letter of the GPL. Some purport that it has increased the usage of Linux in the enterprise; that's a claim for which I don't have the numbers to verify or debunk. Honestly, I sort of doubt much of anyone really does.

Now, I'm a happy OpenSuse user (loving zypper in 11, btw), and I'm very happy to see F/OSS friendly companies succeed .. but I'm not exactly rushing out to recommend Novell to everyone I know mostly because of my personal uncertainty around this whole deal. I doubt anyone at Novell particularly cares about me and my quietude, of course. =)

So I read this latest announcement, thought about the implications of it and then moved on .. until I was spammed by Novell's marketing department asking what I thought about the press release. They said that if I wanted, I could even ring up their director of marketing via instant messenger and chat about it! This is a good example of public opinion management: they evidently know that it's a sensitive area and so are trying to head off any problems by engaging people in the community directly and early on. Very early on in fact: I received my email just a few minutes after the press release was sent out and they attached a PDF of the press release to the email for my reference. Well done! (I mean that: it was a well executed plan.)

And since they asked, I thought, "Sure, why not share my thoughts!" However, I thought I'd do it here instead of over AIM or Yahoo! Messenger with Justin S., partly because I don't like being managed by other people's marketing departments, but mostly because too many of the people who do speak in non-positive terms about this deal tend do so with argumentation that is too easy to discount by simply playing the "let's be reasonable" card.

Not all of us who have issues with this deal are cranks, lunatic fringers or "FOSS community whiners" (to quote one rather snide ZDNet blogger).

I personally think that Microsoft has two roads ahead of it: continue to fight F/OSS harder and harder (and ultimately drown under a rising tide) or slowly change their course and become a true ally of F/OSS (and continue to be relevant in the tech industry). This is not unlike the changes IBM ended up having to make as a result of the events in the 80s and 90s, and it will likely take just as long to see it through. Is Microsoft's partnering with Novell a sign of them taking the former course, or the latter? I don't know, really; I do hope for all our sakes that it's the latter.

But what I do know for sure is this: it is very unfortunate that the deal is being successfully used (hijacked?) by Microsoft to continue to push the idea that Free software, and Linux in particular, caries with it a business risk in the form of intellectual property violations that leave users of it legally exposed. I think the implication that Microsoft should be allowed into the hen house, so to speak, under the pretense of "being robbed of their property" is ludicrous. It is unfortunate that Novell is involved in such a way that it makes it look like they, too, believe in and support this point of view.

The first sentence of the join press release is this: "Microsoft Corp.
and Novell Inc. are announcing an incremental investment in their relationship to meet accelerating customer demand for their business model solution, which is designed to build a bridge between open source and proprietary software to deliver interoperability and intellectual property (IP) peace of mind for organizations operating mixed-source IT environments." (Emphasis mine.)

Whatever can be said about the rest of the deal, the "IP peace of mind" bit is a classic fear, uncertainty and doubt campaign. It's not unlike SCO's "buy a license from us and be safe!" strategy from a few years back, really. Well, except that this program is actually successful: people are buying it, and that gives Microsoft's claims a legitimacy that they can then use to shop these claims around to the rest of the marketplace against Linux and F/OSS in general.

I can't help but walk away with a poor taste in my mouth because of this recurring theme that taints nearly every official communication from Microsoft and Novell surrounding it.

I wish Novell all the success in the world as they have bet their farm largely on FOSS, and I applaud that move. Their success will be all of ours, a validation of the model. But I also hope that in the process of being successful, Novell can avoid helping others cast aspersions such as we see in this press release upon the FOSS world.

(In case it isn't sufficiently clear, I'm speaking my own personal mind here as a private citizen; this blog entry should not be construed as reflecting the thoughts or positions of any projects or companies I may be associated with. I say this only because on matters such as these, I know there are others who disagree and I would not want to appear to represent them against their own opinion.)

associating widgets with mimetypes

One of the neat features in Plasma is the ability to associated widgets with mimetypes. To associate a widget with a mimetype, you add a X-Plasma-DropMimeTypes key to the .desktop file for the widget.

For instance, the picture frame widget has this in its .desktop file:

X-Plasma-DropMimeTypes=image/jpeg,image/png

When I drop an image file onto the desktop, I get asked if I'd like to make a picture frame or an icon out of it. In 4.2, I can also drop raw image data onto the desktop and it does the same (except it doesn't give the option to create an icon for it as it isn't actually a file).

The way this works is that Plasma::Containment queries the widgets to see which, if any, supports the mimetype(s) in the drag object. It's smart enough to follow the mimetype priority if there is more than one type offered in the drag, so html content will be dropped as html content and not plain text. On my 4.2 system, that results in the mini-browser widget being created.

Inside the widget itself, the first argument passed in on the args list will be the URL to a file containing the data. In this way, the widget doesn't need to concern itself with caring about the difference between a "real" file and a blob of data dragged onto the Containment.

Inside the widget, the code can check for this in the constructor with:

KUrl url;
if (args.count() > 0) {
    url = args.value(0).toString();
} else {
    // do some sort of default set up instead
}

That's all there is to it: one line in the .desktop file and a couple lines in the widget itself.

For the user, it means they can drop "stuff" onto their desktop and the Right Thing(tm) happens depending on the content in the "stuff" without them having to do anything particularly special at all.

I'll be extending this to wallpapers as well so that wallpapers can also say, "oh yeah, i support that kind of data", which will result in the addition of a "Set as wallpaper" to the menu that pops up. Which means you will eventually be able to drop an image file onto a containment and choose between creating an icon shortcut for the image, creating an image frame widget for it or setting it as the background. And by "image file" I mean any file type that is supported by wallpapers or the image frame.

I think this could have some really cool applications if people use their imaginations a bit. To get you started: what could happen when a contact is dropped onto the desktop (e.g. a vcard or maybe even a contact listing from a social networking site)? what could happen when an email is dropped from kmail/thunderbird/whatever? what could happen when a movie is dropped? what could happen when a vnc connection is dropped? what could happen when a torrent is dropped?

What might be extra neat here is when combined with other widgets, like folderview and nepomuk. If the user is looking at a folderview showing all video files, once we have a working video player plasmoid the user could just drag one of these videos to the desktop and watch the video play without starting up another application. In fact, they could drag a couple of them onto the desktop and have multiple videos playing. And it would all Just Work(tm).

Now consider using something like this within an application ... say for instance Amarok2. You drag a movie into its plasma-driven context view, and it could quite easily pop up the movie widget with approximately 0 lines of code inside of Amarok2. I don't know if the Amarok2 peeps have such a thing planned, but it demonstrates the concept, one that could probably be extended to other applications as well.

I plan on playing with this auto-widget-generation-based-on-mimetype on small form factor devices as well as a way to perhaps limit the crazyness of opening entire apps for simple processes. Of course, on those devices it probably won't be triggered by physical drag 'n drops, but the idea and code paths will be the same. I'm not sure yet just how useful it will be in that context, but there's only one way to find out, right? =)

Note that in 4.1, drops are limited to applets or files. It's only in 4.2 that we have the non-file drop support (e.g. directly from a web page to the desktop, or from the image thumbnail in ksnapshot to the desktop). Props to Ivan for pointing out that the drop support should be extended to non-file drops as well, prompting me to flesh out this feature to its logical conclusion.

folderview containment with wallpaper

Below is a screenshot showing folderview as a containment with a wallpaper:



There are still a couple things missing: icon position persistence (so the position when dragging an icon to an area of the screen gets saved/restored between starts of plasma), an obvious way to get at the configuration UI and toolbox actions. (Update: just fixed the toolbox actions.)

Switching to folderview is done via the desktop settings dialog with a combobox right under the Desktop Theme selection. Easy peasy.

Jason Stubb's new systray applet also supports hiding icons; we just need an expand button to give access to the hidden icons. I'm pondering whether the hidden icons should appear in a popup or expand the widget in the panel .. hum hum .. Beyond that, the new systray supports much nicer painting of the icons and specialization of the icons letting us transition to a new spec on X11 that doesn't suck ass by mixing new and old style icons without the user seeing any difference (as well as most likely be able to support win32 systray icons on that platform).

So we have a few rough edges to sand down yet, but things are looking nice.

first day back ... catching up

I'm back home and it felt nice to sleep in my own bed again. Made myself stay up until 23:00 so that I'd re-orient to the timezone successfully. I nearly dropped dead into bed at that point, but woke up at ~09:00 this morning, got up and started working on things. So far the day has been spent almost entirely merging patches, reviewing patches, committing a couple of fixes here and there, going through board email (I was impressed when I counted the board mails in the last year and saw that we do over 300/month on the board list), catching up with the devel lists and replying to mails that had piled up while I was gone.

Still to do includes grocery shopping so I have food to eat in the house, laundry so I have clothes to wear, Google SoC final evaluations, more mailing lists, another handful of emails I need to send out, going through business cards collected at Akademy and as much coding as will fit in between all that. It's going to be a busy day indeed.

At least the cats are happy I'm back; both of them are curled up around me right now sleeping. =)

sitting in LHR

I'm sitting in the airport lounge at LHR (London Heathrow) and other than a small kitchen fire in a restaurant here it's not very exciting. I've been hacking today though .. and now kickoff shows suspend and hibernate entries in the Leave tab if the computer supports them (and they work =), there's initial support for desktop context (aka "activity") in libplasma and i'm working on the 800x480 shell for the maemo and an improvement to PanelSvg for visual blending between a panel and a visual extension (inspired by thinking on the N810 stuff).

The workspace context via Nepomuk is interesting: it will allow other apps to tag data for a given desktop context, get what the current active context is, create new contexts, etc in a way that will allow plasma to integrate and coordinate with extra-plasma concepts, such as contacts that are appropriate to a specific project. The idea is that you should be able to tag a contact with a project/activity/context and when you switch to that activity in plasma, then the contacts plasmoid should optionally show only the related contacts. =)

I've committed a couple of things to svn, but most of it will be committed after my flight home as I'll be working on the airplane to finish these things up. Akademy did it's job, for sure: I'm energized and hacking away! =)

I noticed while sitting here that bugs.kde.org was upgraded to Bugzilla 3 as well! It seems snappy and responsive, though there are still some issues with the theme (no saved searches in the footer, lacking colours in the search lists, etc). There are lots of nice improvements to be seen already though, and I'm sure that the remaining issues will sort out over the next week or two. Great work to all involved! =)

before i go

I'm about to head to the airport here in Brussels to start the journey back home to Canada, but before I check out of the hotel and pop onto the shuttle bus that marks the start of a long day of traveling fast while sitting down I wanted to quickly blog some thoughts that were rolling about my head.

Akademy was really good this year.

It was different than past Akademies in several ways. While we retained the technical focus and the excitement of seeing friends we hadn't seen for a year or more, there was also a new professionalism to be felt in certain sessions. There was also more big picture thinking and we were back to hard core technical issues. I loved listening to Till Adam talk about Akonadi in the taxi one morning with KDE and GNOME people alike about the technical challenges and the very sensible decisions the Akonadi team were making and why, not all of which were immediately obvious but which made extreme sense once explained. I wish Till blogged; it is my intention now to get him speaking more for the project in public though. (Till: you have been warned. You can run, but you can't hide. I am the gingerbread man. ;)

The t-shirts rocked.

As a sign of this general maturing of things, the shirts this year were great. They looked like something you might see a fashion conscious person wearing out to a decent restaurant under a sports jacket. The KDAB shirts were understated and sexy, the KDE Games shirt design was plain awesomeness. Lots of women's shirts were available and quite popular; at the thank you dinner we treated the local team to there were wives and girlfriends wearing them. We've come a long ways from just t-shirts to great looking and well done t-shirts. Our clothing seems to be tracking our general head space. =)

We're opening new worlds for ourselves .. and others.

The Nokia tablets are really just the beginning of this. This project is headed in numerous new directions, all of which we badly need to address and none of which are splitting our community into factions. Instead, we seem to be charting our usual same-direction-with-minimum-oversight paths but with a new kind of focus and intensity. The next couple years will see KDE explode on devices as well as desktops around the world, and not just Linux ones. From Edje to geographical information to non-Linux platforms to mobile to open standards to opening the economy around media ... there is so much to do and so much people are doing!

Thank you for the award.

I also wanted to say "Thank you" to everyone for the Akademy award that was bestowed in my direction at this Akademy. It was rather unexpected, and in no small way the rest of the Plasma team and the KDE contributors to marketing, media and organization have been responsible for the progress made that the award was given for. I thank all of you for making me a part of your team, and for being a part of mine. There are so many people in this project who deserve such a thank you as well, and next year when I'm a member of the jury I'll be sure to get some of those people up there on stage with a metal gear in their hands.

Belgium confuses me at times.

Finally, before I dash for the door, I have to say that belgium confuses me a bit. It's an odd mix of cultures and aptitudes (why are the waffles and chocolate so good, but the rest of the food so mediocre?), of attitudes and weather (holy rain and wind, batman!), of architecture (old a wonderful though very religious, but too many cobblestones) and industry (watchmaking is very, very cool). It'll take a while for me to digest this country in my mind, but I enjoyed my stay here. Perhaps I'll have the chance to return again.

Until I arrive home, au revoir!

5am in Brussels

I leave for home tomorrow, but have one more day here in Brussels. It's 05:00, and C. is getting ready to leave to make her flight out of Charleroi in a few hours. While she's skittering about in the bathroom getting all fresh and pretty and what not, I'm blinking here in semi-dark pondering what to do with the rest of the day.

Yesterday I finished setting up scratchbox on my system, flashing my N810 device with the latest Maemo OS and putting it into R&D mode (oooh, text on boot up! ;). It's a fairly well put together system, and I'm so far impressed with the hackability of it all: lots of intriguing new things to play with in Plasma now, such as location awareness. I have found that the documentation available is pretty long winded in places and contains details that I, as a "casual" hacker on the device really don't care about. Once we have KDE lib packages in the Maemo extras repo, I'm going to put up a very straightforward step-by-step article up on Techbase that cuts through all the fat (with references to the pages with the extra details of course), so that others can get up to speed quickly.

At some point in the next few days I'll be creating a small libplasma based shell just for the Maemo device that has the appropriate resolution for the screen and a new default layout. We decided to take this route because, even though the plasma desktop shell binary on my laptop is only 14k, it still has lots of code that doesn't make any sense on the N810 and missing integration points for things like the "full screen / home interface" button and other hardware features.

The new binary will be very, very similar to the existing one for the desktop, just with a lot less code. From there we'll be creating a couple of purpose-built widgets (e.g. a new full screen app launcher with bling and aimed at this form factor) and containments. The containments should be very small, actually, as they will be very stripped down versions of what we already have.

It will be interesting to see exactly how much code sharing we get out of this part of the project; right now it looks like quite a bit. It's an interesting test of some of the theories behind the Plasma framework.

Another interesting result is that thinking of these small form factors will have impact on the desktop as well: while working on a draft design for a primary UI for the N810 at Akademy with other Plasma developers, we spent some time looking at how best to handle the parade of status icons. We decided we didn't want all of them showing all the time: most of them are only needed occasionally and are just screen noise (and pixel abusers) the rest of the time. Sebastian pointed out that the notifications widget has the interesting property of not needing any UI at all: the notifications that pop up are the only useful bits. From there it was a small jump to realizing that the notifications widget should be the container/manager for things like battery status, volume control, etc. In other words, the new system tray system should also be the notification widget. This seems so amazingly obviously in retrospect, but we needed to have to design for something where every single pixel counts to realize it. We'll end up taking the same route on the desktop (and sharing the results, of course, as such widgets run just as well on a desktop form factor as on a small tablet).

In this case, I'm reminded of the benefits operating system portability, only instead of ensuring code cleanliness form factor portability impacts (positively, thus far) the UI design.

Anyways ... I've got to decide now whether to head back to bed for a bit or have a shower and find some breakfast; to hack all day or head into downtown Brussels for a bit ... right now I think bed is winning. =)

the impossibility of akademy

Each day of Akademy I started a blog entry, and each time I did that someone came up and started working on something with me. So no blog entries, but lots of progress made.

I wanted to have an Edgje (e17 API) based wallpaper plugin to show off, but the QtEdje people haven't yet opened their git repo and the last snapshot is old (by, like, 2 weeks! ;) ... They have working native Edje based plasmoids, and wallpaper is on its way (yay! cool animated wallpapers!), but it isn't in svn yet. Once they get their svn accounts approved (hopefully by next week, once all the sys admins are back home and working on things) it'll go into playground and then into kdebase.

I'll probably end up blogging about all the other things we did (e.g. the stuff on the N810s) when I get home on Tuesday.

Until then .. another great Akademy and KDE keeps plowing ahead.

in the containment

14 of us are sitting in the Plasma Hackers Containment in the BoF building right now, though more have been here through the day, and we'll be working on various things. It's the first time I've had a chance to just sit and hack with the Plasma team this Akademy due to conference talks and e.V. meetings. Let's see what we manage to get done over the next three or four days here.

Of course, anyone who wishes to is welcome to drop by and join us in making Plasma even hotter. =)

plasmoids in firefox

George Goldberg appeared yesterday with a Netscape plugin for Plasma, allowing us to run Plasma applets in browsers that use Netscape plugins, such as Firefox (though certainly not limited to Firefox; many browsers support Netscape plugins).



Get the code with git clone git://repo.or.cz/plasmaplugin.git.

the "problem" with Akademy

The "problem" with being at Akademy is that my already busy schedule gets absolutely saturated and I have virtually no time left over for the fun things in life like blogging. ;)

I did want to check in briefly, however, here on day three. It's mobile/embedded day today and over 100 Nokia N810 devices have been given to KDE developers in attendance who will be working on software for it. Expect to see great things happen in the small form factor space with regards to KDE in the months and years to come, as this is really just the beginning.

Later this afternoon I'm on the panel discussion where the topic is "Driving innovation with Open Desktop Technologies". The panel members went for a pre-panel coordination lunch which ended up lasting over two hours; hopefully a lot of the things we discussed over lunch come out during the panel session.

Yesterday was the ever fun KDE e.V. general assembly where we went over the operations and finances of the society as well as re-tooling our online voting system, adopting a legal instrument that will allow developers to assign their copyrights to KDE e.V. should they wish to (aka "the Fiduciary License Agreement", aka "the FLA") which we put together in coordination with the legal eagles at the FSFE and endorsing a Code of Conduct as well as a community working group that is working to ensure that the community has the infrastructure in place to support the Code of Conduct.

This in turn was preceded by two days of awesome presentations by Free software developers. While most were KDE contributors, there were also GNOME, Mozilla, OpenStreetmap and other developers. The Big Take Away(tm) for me from the presentations was how the Pillars of KDE frameworks are finally emerging from the basement and making appearances in both applications and other frameworks. Seeing the work being done to hook up Akonadi with Nepomuk, Decibel and Plasma was just one such example. Very cool stuff.

The Plasma team did a set of lightening talks highlighting a few of the recent developments in Plasma ranging from widgets on screensaver to new widgets to scripting framework progress. Unfortunately we only had 45 minutes so could only present a small fraction of what's going on now; we probably could have gone on for hours. Well, I could have at least but then I'm the "talkative" sort (or so they tell me ;).

The Dot has great coverage of all these things, so head over if you want to know more. =)

Tomorrow is the usability track, and it's also the day that I'll be starting to actually hack on new things. There are several goals that the Plasma team has identified due to the content of presentations over the last few days and hopefully we'll hit a few of them even before we leave. I'll be sure to keep you posted in the blog here with at least daily entries until I head back to home sweet home Canada in a week's time.

plasma quickies, SoC screencast

I figured that if I'm doing this whole blogging thing again, I may as well keep you all up to date with what we're doing in Plasma on a regular basis. ;)

Today the initial support for wallpaper plugins went in, which means that now you can us folderview as a full screen containment ... and get a wallpaper. Yes, I can hear you all screaming in joy now. I worked up the basic design, put it to the mailing list for review and Petri Damstén claimed the task and managed to get the first fruits in today.

<spoiler>The QEdje guys and I have plans for wallpaper plugins at Akademy.</spoiler>

Jason Stubbs has poked his head up again and has fixed a bunch of things, including a rather mind-numbing bug in the system tray introduced with Qt 4.4.1. Sometimes I feel that the system tray is the $DEITY's way of laughing at us.

Marco's been plugging away at making buttons and tabbars and what not more pretty and Plasmalike; I believe the goal there is to get the weather applet well under way for 4.2.

Services are starting to pop up as well in places like the tasks DataEngine (used to build taskbars and other windowy things) and the nowplaying DataEngine. Alex Merry has been busy pointing out every bug he can find in Service, and often fixing them too, while I added the ability to associate widgets with Service operations. This allows, for instance, the play button to automagically become disabled when the nowplaying Service notices it can't play anything. Neat stuff.

This is also one of the places that the JOLIE service framework will end up plugged into.

Google Gadgets are now supported via a ScriptEngine in kdebase thanks to Dong Tiger. Unversal canvas, here we come.

And finally, we've started merging Summer of Code projects already, with two in trunk right now. In fact, I did up a little screencast showing Extenders (by Rob Scheepmaker) and Screen Saver Widgets (by Chani Armitage). Enjoy!

Update! Apparently sound is not working for some with the avi version, so here is the source ogg straight out of qt-recordmydesktop. Hopefully that works better for those experiencing issues with the avi video, though it is a little bit bigger of a file, by ~15% or so.

Now I'm off to the coffee shop for some quiet time to work on Akademy presentations.

Note: all of the above references work that will not appear until KDE 4.2 is released, slated to happen in January of 2009.

a brief history of time beauty in kde 4

In The Beginning There was a Desktop ...

KDE wasn't always the shiniest tool in the shed. While KDE 1 certainly looked more coherent and generally nicer than most things on UNIX or Linux at the time, it wasn't .. you know .. gorgeous. Things got better over time, certainly, but with KDE 4 some of us decided to try something new and consciously grow the focus of KDE development to include a few key traits we'd been lacking.

At the end of March in 2005 a bunch of people (15, if I recall correctly) gathered for an ad-hoc meeting in Berlin, Germany. There were artists, usability experts, developers, business managers and users. We all had one thing in mind: the future of KDE.

The meeting was by private invite and kept quiet until it was over. This pissed some people off, and rightfully so. KDE's inner culture wasn't as transparent then as it is now, and that showed in this case. But more than anything else, the people organizing it were concerned that it might fail completely ... or succeed in ways we couldn't imagine. It was such a wild experiment that nobody knew how it would turn out.

(Side note .. I do wish they'd carried it out in a more transparent manner from the start and had a bit more confidence in the whole process, but it was a good lesson for everyone. The greater transparency in general in KDE since that era is a nice sign of progress.)

... And Then We Took Berlin

Besides a cute wiki and a beautiful logo, what did we emerge with from that meeting? Well, a few projects that you might have heard of got their start there: Oxygen, Marble and Plasma to name three. Some usability innovations, such as solutions for the select-with-single-click-activation dilemma, also emerged during that meeting.

I summed the results up this way in the wrap-up story for theDot:

"This first APPEAL meeting provided a hot-house for focused, interdisciplinary KDE development. Looking forward, the group aims to grow organically in scope as others with a similar drive for realizing visual beauty, interface clarity and technical creativity in KDE come together. Additional APPEAL meetings are already being planned."

KDE already had a reputation for technical excellence at the framework level, showing prescience with DCOP (later inspiring D-Bus), KParts, KStandardDirs (leading eventually to Kiosk user and group management) and much more. We wanted to add "excellence at the interface level" to that, and to accomplish that we listened to users large and small, usability experts and artists.

We defined targets like "visual beauty", "interface clarity", "interdisciplinary development" and "technical creativity" nearly three and a half years ago as goals for KDE 4. We then set about to spread this meme throughout KDE.

We took an arguably slower bottom-up approach to this because we wanted the results to be sustainable and honest, not a splash of paint that gets done once in a hurry and then forgotten about, left to pixel-rot away over the years. We also didn't want to risk creating schisms in the various project teams in the process. This is the principle of "don't break what's working to fix what's broken".

The Results Are (Coming) In

When you look at what is going on today in KDE it's evident that we've been largely successful in getting this meme embedded in the DNA of the KDE team.

From in-application animations and window compositing to SVG theming and canvas centric applications to a much greater sensitivity towards usability issues it's become pervasive and noticeable. That is a success everyone involved with KDE is responsible for equally, not just the few people who trekked to Berlin in '05 and certainly not just the programmers.

(Speaking of programmers, we're still rocking the frameworks side of life with things like Solid, Phonon, ThreadWeaver and Nepomuk, of course.)

We are still working on coordinating all fronts equally well, but the jump in both looks and functionality between KDE 3.5 and KDE 4.1 are pretty compelling. While there are a few features in KDE 3.5 that aren't in 4.1, there are many, many more features that are in 4.1 which aren't in 3.5.

As for visuals, the two releases don't even compare: it's Apples to oranges (excuse the pun ;) with 4.1 being widely hailed as visually more satisfying. It's also more themable, brandable and adjustable than KDE 3 ever was despite the streamlining.

The jump from 4.0 to 4.1 to the bleeding edge development going into 4.2 right now clearly defines the vector we're on: a near vertical climb skywards.

Why this topic now?

I'm talking about this right now because there has been a growing murmur about beauty in Free software of late:

Mark Shuttleworth put out a call to make the user experience of desktop Linux even "prettier" than that of Apple's Mac OS.'

Analyst Stephen O'Grady agrees with Mark, and even notes that he wrote about this exact issue back in March of '06 in a blog entry entitled "Pretty is a Feature".

In one KDE 4.1 review written by Darryl Taft for eWeek, two and two were put together when Darryl wrote: 'Perhaps KDE is working toward that goal.'

And so we finally get to the punchline: Yes, we are working towards that goal.

We started building the necessary momentum and support structure for this push three and a half years ago when we we set for ourselves a Big Hairy Audacious Goal (BHAG) at the Appeal meeting:

"Put people in front of two machines: one running KDE and the other MacOS. Let them experience both options from log in to shut down, and have them leave wanting KDE."

Are we there yet? I don't have empirical data to point to (though I personally feel "not yet"), but I think we're getting damn close. Most importantly we have the right mindset and the right trajectory to meet that BHAG. That's something very few other software projects can say with similar confidence right now, F/OSS or otherwise.

And this is why KDE is so valuable in the F/OSS ecosystem: we have a culture of anticipating the needs of the near future and working on quality solutions for them before most people even wake up to the issue.

Be Free .. (To Sell KDE)

Now if this sounds like I'm trying to sell the Shuttleworths, O'Gradys and Tafts of the world on our vision and our team, you're right. There it is, I've said it openly. =)

We have something hot going on: something that scales up and down the hardware spectrum, something that is looking sexier practically by the minute, and something that is built for the future ... something that we have oodles more room to explore within and well laid plans for executing on that.

Most importantly, the ability to create that "something" is part of our culture right alongside "make great library frameworks".

That culture is precisely what the F/OSS desktop needs right now, and we should be building our successes on it together.

p.s. Maybe it's time for a second (more open) Appeal meeting.

4.1 is out and i, too, am going to akademy.

KDE 4.1 was released last week and there has been a lot of positive coverage in the press and the blogosphere about it. (Side note .. The promo team is busy collecting a list of these articles and putting them together for publication on kde.org.)

With the release of 4.1, KDE executed on our collective commitment to release in July. More importantly, that release fulfilled the milestone we set out for ourselves: a day-to-day usable desktop shell, more polish on the applications, lots of bugs fixed, more platform coverage and more application porting underway.

Make no mistake about it: 4.0 was absolutely required for the development team to successfuly unfold KDE4 over the coming years; but with 4.1 it is indeed time to look forward, not back.

So .. looking forward:

The hiatus is over: I'm back. Well, I was never really gone, I was just unvisible ("un-" being more pink than "in-", and pink being the new black).

The KDE community has brought a number of important modifications to our community infrastructure to the table. Many of these are in "alpha", if you will, right now and will be making their way out into production over the next several months.

The variety of initiatives is impressive, ranging from a draft of a Code of Conduct that will hopefully get a general viewing during Akademy to comment moderation on the Dot, and lots of other things, big and small, in between.

This momentum has restored my personal faith in this community of contributors. I feel, once again, that we are able to take care of each other and not just sit idly by while Rome and its inhabitants burn. While it saddened me to step back, perhaps it was necessary to help get focus on issues that were being neglected by us all. It also gave me some space to catch my own breath.

To those who have put time, thought and energy into working on these topics: thank you!

Now let's get back to what we're all here for in the first place ...

Akademy 2008 is upon us. At the end of this week a few hundred of us start gathering together in Belgium for what is shaping up to be one of the best Akademy events ever, which is saying a lot given the past installments.

KDE e.V. has sponsored more travel than ever (nearly twice as much as two years ago and over 20% more than last year) and the program looks fantastic. The Embedded & Mobile Day is going to be great (Plasma is already being used in product development in this category, so this topic is even more relevant to me now); the workshop led by Nokia engineers should be fun (playing with N810s! yay!); the Usability Day will be very fruitful (I'll be doing a presentation in that track; I hope to see work on the HIG reivigorated). And I can't wait to see what the BoFs will end up being like this year.

I also know of a couple of release announcements that will happen at Akademy, but I don't want to spoil the surprise for others so I'll (painfully) sit on these things until next week. Pay attention though, because some cool stuff is going to emerge!

As usual, the KDE e.V. AGM will be a roaring blast, or at least as roaring a blast as 7 hours of meeting mandated by and presided over by German law can be. ;) (Honestly, they are actually pretty good. =) Apparently I have to deliver the assembly opening, which I have yet to write. I promise to keep it short and sweet.

At the Plasma Frenzy at the end of Saturday, the Plasma team will be presenting a series of 5 minute lightening talks on various aspects and features of Plasma. We will cover such things as extenders, new applets (the UIServer and Notify ones, for example), scripting, API strategies, Plasma-on-screensaver and more.

I'll also be staking out a Plasma Tokamak area for the hack week where I'll be (mostly) planting myself to discuss and work on all things Plasma. If you are looking for me, (even if it isn't about Plasma =) that's where you will be able to find me .

And just in time for Akademy 2008 ...

... KDE 4.2 development has begun. I think we are all proud of our achievements with 4.1, but we're not standing around patting each other on the back with drinks in our hands.

There is so much left to do and so much yet to explore in terms of what is possible with our new frameworks and applications. The goal has become to fully realize the potential imbued in the KDE4 foundations and pillars.

Thanks to the work to date and most notably the 4.1 release, we've gotten to the point where the code is really fun to work with and the results very enjoyable to use. We're back to the job of adding features, refining existing bits and fixing problems. In other words, we're doing evolutionary development and releases again.

With 4.2 having opened up for feature work in July, the Plasma team started off with not just a bang, but a Big Bang: two of our Summer of Code projects have already been merged into trunk with more on the way, and a number of features that had been lurking about in playground have also been folded in. There have also been numerous bug fixes and polishings done in July to both trunk (4.2) and the 4.1 branch.

To give you an idea of our current progress on 4.2, here is the current change log of notable improvements since 4.1 was branched off for release:

libplasma
---------
* Features
   * Symbol Versioning: limit loading of plugins to those that match the libplasma version
   * New: ToolTipManager for Plasma style tooltips
   * Applet
       * sizeHintChanged() signal. A containment (such as a panel) can adjust its size based on changed sizehints of an applet
       * NEW: Plasma::Extender and Plasma::ExtenderItem, allowing visual, relocatable extensions to Applet
       * NEW: PopupApplet, which switches between an icon with a popup in a Horizontal/Vertical containment (such as a panel) and the widget directly on the canvas in a Planer containment (such as a desktop)
   * Corona
       * addOffscreenWidget/removeOffscreenWidget: manage canvas items that should not appear in a primary view (e.g. Extenders)
   * Package system:
       * PackageStructure supports arbitrary URIs (in addition to auto-discovery for package) structure description files.
   * Plasma::Theme
       * Support compressed SVGs (*.svgz)
   * Widgets
       * NEW: Plasma::Slider based on QSlider
       * NEW: Plasma::TabWidget
       * NEW: Plasma::Frame used to visually group widgets
       * Plasma::PushButton is svg-themed
   * Panel SVG
       * setting the margins via in-SVG hints
       * paintPanel API additions to make it more like QPainter and Plasma::Svg

* Significant Fixes
   * WebContent painting update synchronization (fixes, among other things, scrolling)
   * Prevent crash when Containment that AppletBrowser is associated with is deleted
   * Applet handles work with all icon sizes (user system settings)
   * Fix View so that when a new activity is added, don't move more than necessary;
     fixes dragging lock

Developer Documentation
-----------------------
* Design documentation
   * NEW: tooltips
   * NEW: wallpaper
   * NEW: widgets

* Tutorials

Desktop Theme
-------------
* NEW: widgets/button for theming pushbuttons
* NEW: widgets/frame for theming Plasma::Frame used also in other widgets

Plasma Desktop Shell
--------------------
* Features
   * Panel
       * resizes itself when an applet changes its sizehint according to its maximum and minimum sizes

* Significant Fixes
   * Reposition toolbox when zooming out/in to avoid panel overlap
   * MS Windows compile fixes

Plugins/Addons
--------------
* Features
   * Plasmoids
       * NEW: Calendar
       * NEW: Character selector
       * Now Playing media player controls
       * Notes
           * Custom colors
       * Digital clock
       * Custom colors
   * Folder view
           * Filtering improvements: mimetype and exclusion based.

   * DataEngines
       * nowplaying Plasma::Service for controlling media players
       * nowplaying supports MPRIS

* Significant Fixes
   * Various clocks ported to AppletClock for calendar and timezone consistency
   * Kickoff menu size restoration
   * MS Windows compile fixes
   * Taskbar shows thumbnails of windows on hover (4.1 regression)

KRunner
-------
* Features
   * Plasma Screensaver: Plasma widget overlay for screensavers

* Significant Fixes
   * Screensaver activation fixed to compensate for system clock changes

Note that this is not our feature plan (we have one of those, too, of course =). Rather, this is what we've already done and will be part of the KDE 4.2 release in January 2009.

We still have a nearly 6 months of development ahead of us with a large number of features, fixes and streamlining activities in the pipeline. More goodies will follow, and if you wish you can follow the change log as it evolves here.

If Plasma is any indicator of the overall level of activity in the rest of KDE, 4.2 is going to be an insane release, especially since we'll be joined by apps like Amarok2 by that point.

To put it all into perspective: KDE3 had 6 years of development on it after 3.0, KDE4 has so far had 6 months. Think about it. =)

Wade Olson's inspirational KDE themed Picasa albums, from which many of the above graphics were borrowed.