Plasma Active – A Desirable User Experience Encompassing the Device Spectrum

Plasma Active on a tabletToday, I’d like to announce to a wider audience a project we have been working on in and beyond the Plasma team. Its goal is to “Create a desirable user experience encompassing a spectrum of devices“, and it is called Plasma Active. A couple of things make Plasma Active special. First, the driver is the desirable user experience. That means that we want to create something, people want, and people want to use. It means we are less technology-focused, but are taken a user-centered approach. Second, we are not targeting a single device, or a narrowly-defined class of devices. Plasma Active is made to run on a spectrum of devices that make up the user experience together. Devices change, and so does the way the user interacts with them. By strongly separating data and visualisation / interaction, we do not re-invent the wheel but adapt to the requirements and expectations of a device, and about how devices work together for the user.

Running Plasma Active

We have a basic, Plasma-based shell right now, which runs on three target devices — and probably some more, but that’s what we’ve tested so far. It performs well, runs stable and is usable with a touch-screen. While Plasma Tablet is quite fun already, do not expect release quality yet, as it is a snapshot of our efforts. Find the download location for the Balsam Professional live image on the wiki.

open-slx has created a Balsam Professional live image based on openSUSE 11.4 running Plasma Active. open-slx (my employer) are developing Plasma Active for openSUSE in the openSUSE Build Service. We’ve also created packages which can be installed online on top of openSUSE 11.4. You can find installation instructions in our Wiki, also for Meego.

Of course you want to run Plasma Active on a ‘real’ device, we currently recommend either the ExoPC (WeTab), the Lenovo Ideapad, or a Viewsonic Viewpad 10. You can find instructions for devices in the Wiki

The demo video shows Plasma Active in action on a Viewsonic Viewpad 10.


There is still a long way to go. We’re missing key functionality, default applications, optimizations all over the place, and more. There is nothing fundamental that holds us back to bringing the full experience users expect to tablet devices, based on our well-known, beloved, proven software stack. We are focusing our first release, which is planned for September already, on tablet computers.
Since fixing a bunch of showstoppers over the past two weeks, I’ve actually started using Plasma Active for some light reading tasks (mostly web and RSS), and I’ve got to say: It rocks your socks. Being able to use a tablet computer which is based on Free software that you created yourself, is real fun. I’ve also handed it to friends who came by, and while they understood it’s an early prototype, I had a really hard time getting my gadget back. And that is only just the beginning. We have an excellent base to build a complete experience upon. In other words, it’s the perfect time to jump in and become part of something great and to help it also making it something really big.

Different goals need different processes

Widgets on Plasma ActiveWhen we put the pieces for Active together, it quickly became clear that if we want to succeed, we also have to rethink some of our collaboration processes. One of my pet peeves has always been that different essential parts of what the user gets in her hands come from different teams. If we want to put something desirable into the hands of our users we need to pull in the same direction. While we needed different skills, these skills have to align in how they’re applied. This makes communication more natural, leads to a more focused process, and ultimately a better result. It’s clear that such an endeavour will only work if enough people in our communities, and the communities around it think that this is a worthwhile thing to spend their time on, and that we can get the people that do to pull in the same direction. The good news, however is that we’ve been able to create a stable platform to do this, in terms of tools, processes, collaboration models and not at least software. That platform is Plasma Active.

Sounds interesting?

If you want to help us shape Plasma Active, and bring its vision to reality, we would like to invite you. Start with having a look at our list of tasks, and if you find something you can help with, tell us, subscribe to the Plasma Active mailing list, or join #active on Freenode’s IRC network. We have documented our ideas, concepts and processes in the wiki.

In the coming weeks, we will keep you updated about Plasma Active’s progress, and we will be able to reveal more of our vision as we give Plasma Active shape by making it become reality.

Bretzn vorgestellt

Der Bretzn Qt Creator PluginSoftwareentwicklung ist eine nicht ganz triviale Sache. Erstmal muss man natürlich programmieren können — das ist der spassige Teil. Hat man dann allerdings etwas Cooles geschrieben, muss man noch dafür sorgen, dass es irgendwie zum Anwender kommt, und dort in’s System integriert wird. Dass heisst für Linux, dass man Pakete braucht, und ein Repositorium um diese bereit zu stellen. In Zukunft kann man hier auch an Appstores denken, hierzu allerdings später mehr. Um also einerseits dafür zu sorgen, dass die Software installiert werden kann, andererseits aber auch dass die Entwicklung und Bereitstellung für Entwickler attraktiv ist — und damit das Angebot an Software vergrössert — sollte der Prozess so einfach wie möglich sein.

Vom Code zum Paket

In den letzten Monaten haben wir bei open-slx daran gearbeitet, den Prozess vom funktionierenden Code zu installierbaren Paketen zu vereinfachen. Wir haben uns also mit Nokia und h i v e 01 zusammengesetzt, und einen Plugin für Qt Creator entwickelt, der es einfach, fast trivial, macht, Code zum openSUSE (oder MeeGo) Buildservice hochzuladen, dort zu übersetzen, und als Paket bereitzustellen. Hierzu haben wir libattica erweitert, eine Bibliothek, die die Open Collaboration Services in einer API in Qt Stil anbietet. Auf diesen API Erweiterungen baut ein Plugin auf, der es möglich macht, mit ein paar Mausklicks Software zu paketieren, und dann über die Repos die am OBS hängen anzubieten. (Dies hat zwei Vorteile: RPM Spec-Dateien werden automatisch erstellt (das passiert auf dem OCS Server, der die Kommunikation mit dem OBS relayt), und die Software kann vom OBS für verschiedene CPU Architekturen und Betriebssysteme paketiert werden, was die ganze Arbeit erspart, Entwicklungsumgebungen für allerlei unterstützte Systeme vorzuhalten.

Im Video kann man sehen, wie das funktioniert. Es werden einige Metadaten eingegeben, Accounts eingestellt, und der Code wird hochgeladen. Danach kann man einfach den Buildjobs für verschiedene "Targets" anstossen, sodass das Paket dann z.B. für openSUSE 11.3 auf einem 64 Bit Intel System läuft. Der Prozess verläuft dann grösstenteils in der "Cloud", d.h. auf dem OCS und OBS Servern. Auf dem Client braucht man ausser der eigenen "normalen" Entwicklungsumgebung nur den Qt Creator Plugin zu installieren, d.h. keine chroot oder virtuelle Maschinenen aufzusetzen, oder ähnlich arbeitsaufwändige Dinge.

Im Laden

Prototype AppstoreEs stellt sich die Frage, warum dies über OCS passieren muss, und warum man nicht direkt mit dem Buildservice über die REST API oder Werkzeuge wie "osc" kommuniziert. Die OCS Schnittstelle bringt einerseits Appstore Integration, andererseits auch soziale Features, und in Zukunft vermutlich auch ein Abrechnungssystem (die Plattform soll ja auch attraktiv für solche sein, die für ihre Programme Geld verlangen möchten). Im Appstore Sprint, der kürzlich in Nürnberg stattfand, wurden einige Fragen zur Clientseite besprochen, und ein erster Prototyp entwickelt. Der Ansatz hier ist deutlich: Im Gegensatz zu ‘traditionellen Paketmanagern’ gibt’s hier auch eine soziale Komponente: Benutzer können Software kommentieren und bewerten. Ausserdem ist die Benutzeroberfläche ansprechender gestaltet und bietet Screenshots und möglicherweise Screencasts. Benutzer können Benachrichtigungen bei neuen Veröffentlichungen oder Updates abonnieren.

Mehr Informationen hierzu könnt ihr auf den folgenden Seiten finden:

open-slx end-user platform announced

A couple of months ago at open-slx, when we (like so many times before and after) talked about how we can make the lives of Linux users easier, an idea was sparked. While there’s huge amounts of content out there, it struck us that there’s still a large number of people not being too well served when searching Google to get answers to your questions. This poses some problems though: First of all, most of the information is not in English. This poses an extra barrier for some, who might not be as fluent in English as we developers usually are. Then, the content is hard to verify: How do I *know* that the information given there makes sense? Maybe it will just delete all my erotic movies? ;) So the problem is that there’s little content for the German end-user audience, which is hard to verify. So a team consisting of openSUSE community members and open-slx employees led by my colleague Rupert Horstkötter has set out to fix this problem. They looked into existing solutions to these problem, and found that what is currently running as comes closest to the solution we have in mind. We got in contact with the team at, and they were enthusiastic about the idea and willing to make it happen. A good start.

Then comes the real work of course. We’ve worked out a concept that allows us to provide a modern support tool for our users, which builds on two pillars: information and interaction. The concept we come up with puts this into three different tools: a wiki as knowledgebase, a forum to discuss articles, questions and to get in contact with other people, and a blog aggregation (Planet) which collects news about developments in openSUSE and howtos for specific topics. In order to accomplish this gargantuan task, we’ve asked for help in the openSUSE community. People were immediately enthusiastic about the idea, and started chipping in, helping to review and improve lots of articles.

Over the past few months, we have reviewed about 2000 articles from the existing knowledgebase, prioritizing 500 of them, and adapted the articles to modern standards and that they apply to openSUSE. These 500 articles form the foundation for the knowledgebase we created for the open-slx community platform. We’ve also set up a webforum users can use to communicate and ask further questions, and we’ve put up a blog aggregator.

So, if you’re a German-speaking user (or future user :)) of openSUSE, hop over to and see for yourself whether this new platform fits your needs (and if it doesn’t, let us know what we can improve). You can find the official announcement here.

Solides 4.6: Neuerungen in der KDE Hardwareverwaltung

In KDE Plasma 4.6, dass im Januar erscheinen wird, sind so einige Sachen, die den Bereich Hardwaremanagement verbessern. In diesem kurzen Artikel highlighte ich zwei davon: Netzwerk und Powermanagement.


Netzwerkkarten Details im Networkmanager PlasmoidHier haben die meisten Änderungen unter der Haube stattgefunden. KDE’s Hardware Abstraktionsschicht Solid kommt jetzt gänzlich ohne HAL aus und baut auf die U* Familie, die aus UDev, UPower und UDisks besteht. Eine Änderung in Solid ist, dass jetzt mehrere Backends gleichzeitig ihre Arbeit machen können, was auch notwendig ist, da das monolithische HAL durch die modulareren U* Komponenten ersetzt wurde. Für Applikationsentwickler ändert sich allerdings nichts, alle Solid Funktionen funktionieren nach wie vor, nur benutzen jetzt im Hintergrund einen anderen Mechanismus um ihre Arbeit zu machen.

Eine weitere Änderung hat das Solid Team in mit PowerDevil2 eingeführt. PowerDevil ist ein kleiner Daemon (eigentlich ein Plugin für den KDED) der verschiedene Energiesparfunktionen bereitstellt, wie z.B. das Suspenden der Maschine und Energiesparprofile. PowerDevil2, der in 4.6 neu ist, ist modular aufgebaut und kann mit eigenen Aktionen erweitert werden. So können Benutzer das Verhalten der Energiesparfunktionen komplett selber bestimmen, und sind nicht mehr von hardcodierten Funktionen die mitgeliefert werden abhängig. Diese Action Plugins integrieren sich nahtlos in die Profileinstellungen, wie man auf dem Screenshot sehen kann. Das Batterie Plasmoid, über das auch andere Energieverwaltungsfunktionen, wie z.B. Suspend und Hibernate verfügbar sind glänzt im 4.6 Releasezyklus vor allem durch Bugfixes. So habe ich diese Woche noch 4 Patches, die Aurelien bereits in den Trunk Zweig eingeplegt hatte auf das bereits abgezweigte 4.6 Branch zurückportiert.

Für 4.7 plane ich, erweiterte Informationen über den Energieverbrauch und Zustand der Akku(s) hinzuzufügen, ich habe mit der Entwicklung davon bereits begonnen. Dazu allerdings mehr zu einem späteren Zeitpunkt, jetzt liegt erstmal der Fokus auf Plasma 4.6, und danach darauf, das openSUSE 11.4 Release rund zu gestalten.


Energieverwaltungs EinstellungenopenSUSE liefert im 11.4 Release, das auf KDE 4.6 aufbaut das neue Netzwerk Management Widget mit, ein Plasmoid dass es erlaubt Netzwerkverbindungen aufzubauen. Im Hintergrund baut es dabei auf den bekannten NetworkManager auf. Um die Jahreswende sind hier vor allem noch VPN Funktionen hinzugekommen, dank einiger freundlicher Entwickler, die mir Patches zusandten. (Ich selber benutze kein VPN, bin daher auch auf die Mitarbeit anderer angewiesen.)
Ansonsten unterstützt das neue Applet Wifi und Ethernetverbindungen sehr gut, ist aber auch für’s mobile Internet bereits gerüstet. Die Integration des Modemmanagers ist bereits weit fortgeschritten, und sollte funktionieren. (Auch hier kann ich’s nicht selber testen, falls es hakt bitte Bugreports einstellen. Wer drahtlose Netzwerke benutzt, die ihre SSID nicht broadcasten, d.h. die "unsichtbar" sind, hat im Moment leider noch Pech, die Unterstützung für diese Netzwerke ist noch nicht komplett. Man kann sich aber behelfen, indem man (als root) "iwlist wlan0 scanning essid <MYSSID>" ausführt. Danach ist das Netzwerk in Plasma sichtbar, und man kann sich damit verbinden. (Dieser Vorgang ist nur einmal nötig, da das Netz nun in Zukunft direkt erkannt wird.) Visuell bin ich mit dem Netzwerkeinstellungsplasmoid schon recht zufrieden, d.h. im Grossen und Ganzen tut es das, was es sollte. Es gibt noch einige Sachen, die ich kurzfristig beheben möchte, so kann es vorkommen, dass die Liste auf der rechten Seite leer ist, d.h. keine vorkonfigurierten Verbindungen zur Verfügung stehen. In dem Falle sollte man drahtlose Netzwerke in der Nähe sehen. Meinerseits liegt der Fokus hier also vor allem auf Polishing und Bugfixing, sodass es nicht nur cool aussieht, sondern auch so reibungslos und unauffällig wie möglich funktioniert. Es sind allerdings auch nette Features wie Unterstützungen für "system connections", die dann auch aktiv bleiben, wenn man ausloggt.

Running for the openSUSE Board.

I’ve just sent off an email, in which I’m announcing my availability as candidate for the openSUSE board, which will be elected in early 2011. Here’s what I wrote:

Hey openSUSE community, valued election committee,

Following up on the call for candidates, I’d like to let you know that I’m intending to run for the openSUSE Board.

In my dayjob, I am responsible for user experience at open-slx, and will be able to invest time on a regular basis into participating in the openSUSE board. I have a degree in business science, which gives me some formal insight into organisational processes, this has helped my work for the KDE e.V. in the past, and it will surely be benefitial for openSUSE. I am 34 years old, and live in Nijmegen, in the east of the Netherlands.

I have more than 4 years of experience in administering a Free software project (I’m member of the KDE e.V. board since 2006), and during this period have helped turning the KDE e.V. into an effective community representation and supporting organisation, which in many ways acts as a role model to other, similar organisations. The Geeko in me is about 9 years old, it started with openSUSE 7.2, which got me hooked on Linux. After a period of trying all kinds of Linuxen, I’m firmly back to openSUSE for about two years now.

openSUSE represents to me a technically excellent product with a friendly, helpful and skilled community around it that is failing to realise its potential, and in many ways is searching for orientation and a clear mission. Aside from organisational topics, this process I’d like to facilitate.

My platform for the elections is to help set up the openSUSE e.V. (or rather a legal representation of the community, as outlined in the current plans), and to help the community through the process of becoming more independent from Novell, which in my opinion is important for the growth and sustainability of openSUSE as product and community. I’m a Free software dude by heart, and the principle and ethics of the Free software community will be what drives my decisions as executive. My experience as "cat-herder" will be beneficial in the same way.

I do realise that my involvement in the openSUSE community has been fairly transparant, following things from the sideline, stepping in actively here and there, and certainly far from taking on any role as rock-star. I am planning to further ramp up my profile, since that a) will make the members’ decision during the elections a lot easier, and b) it improves accessibility and visibility of the TOTRoS (The Organisation That Represents openSUSE).

This email is just to let you know in advance that I’m intending to run for the board. As I /also/ intend to go on vacation on Friday, I might appear unresponsive until ~christmas. Still, I opted for letting everybody know early on that I’m intending to run (rather than sending my note of intent to run after christmas), as planning will likely make the work of the election committee a bit easier.

Surely, if you’ve questions already, feel free to ask. I will, after returning from vacation be more outgoing about my involvement with openSUSE and my ideas and plans for the openSUSE board.

Thanks for your attention, and your support.

*jumps off the soapbox*



openSUSE conference 2010

These October days, I’m spending in Nürnberg in Southern Germany to attend the openSUSE conference. My role here is three-fold, first and foremost I am here as a representative of open-slx, my employer who sells products and services based on top of openSUSE. Then, I’m a KDE ambassador. Finally, I’m also getting more and more involved with the openSUSE team, getting to know many people and learning about challenges and opportunities this community faces.

That last one is actually really interesting, as the openSUSE community is in the process of re-finding itself. There’s the discussion about strategy going on, which is I think mainly formalizing the biggest problem openSUSE has: It’s lacking a common direction. This is a symptom of good and bad things, it reflects the diversity in the openSUSE community, which I think is of great value. On the other hand, it makes it hard to deliver one coherent product as there are nearly as many goals and opinions how to reach these goals as there are people in openSUSE.

Another part of this process is the de-coupling of the openSUSE community from Novell. This independence is very important for the Free software community since it means taking your own decisions — for instance about the direction of the product. Now my impression is that Novell doesn’t want to abandon openSUSE, but it’s trying to make it stronger by giving it more independence, it’s some sort of growing up of openSUSE.

Yesterday, I attended a session about setting up a foundation for openSUSE that can manage funding, governmental aspects and other more organisational tasks. Interestingly, the openSUSE board has (after looking at many comparable organisations in the Free software space) taken a direction very similar to how KDE with the KDE e.V. backing it up is set up. This is good to hear, since on one hand it validates the work we’re doing in the KDE e.V., and it’s yet another way of sharing in the Free software ecosystem. (Actually, we get requests for organisational assistance from Free software or Free culture projects on a somewhat regular basis.)

I’ve just attended a talk by Cornelius and Vincent (KDE resp. GNOME) who were talking about freedom in the cloud, giving a nice overview how the values of Free software apply to application used from the cloud. The rest of the day is packed with technical sessions, which I’m really looking forward to, and towards the end of today, I’ll talk about user experience in openSUSE. Actually, I’ve decided to talk about user experience and interaction design in general, explaining typical design processes and tools. I aimed for a talk teaching and explaining techniques this time around, since I think that this applies best to a community from kernel hackers to UI designers. My hope is that people will take away some ideas of how to improve the user experience of their work.

Getting Email Done: The Stack and the Heap of Lion Mail

In my previous article on this subject, I have introduced Akonadi as the personal information beehive on your computer, explained how it works, how it is designed and what the migration process to an Akonadi-based Kontact looks like. (openSUSE users should also take a look here.) In this article, I will dive into the workspace parts we’re introducing on top of Akonadi, notably the new email notifier system in Plasma – Lion Mail.
The Lion Mail email notifier is at its base your "you’ve got mail" icon in the panel. For users with more complex and high-traffic email habits, it offers a basic set of workflow tools to manage the daily stream of emails more efficiently and ergonomically. In this article, I’m describing some of the design concepts behind Lion Mail’s email notifier and its workflow features.

In the panel, you can quickly see if there are new emailsComplex email workflows are something I wanted Lion Mail to excel at. The idea is to make dealing with email as flexible as we can, so you can project your workflow onto it and have it make the daily flow of email more manageable, and less disturbing in the real work you want to get done. By default, the Lion Mail email notifier shows up in your panel when a new email arrived in your inbox, by clicking on it you can access the list of your latest unread emails in a small popup-window. The basic use-case is quickly checking if you’ve got new email. I will not dive too much into implementation details, as this article is all about work-flows and how it affects the user experience.

The idea is that, at all times you can see if there’s email to deal with. but not have it jump in your face. In order to be able to quickly dismiss something as "I’ll deal with that one later", or "ok, got it", there’s two queues in Lion Mail, the stack and the heap of Lion Mail.

The Stack — Incoming Emails

The popup shows a list of the new emailsThe stack is your incoming emails queue, it lists new emails in one or more folders. By default, that’s your inbox, but you can configure it to monitor any folders you like (yes, combining them from multiple folders is built-in). The incoming emails queue is a transient thing, it’s your stream of incoming emails, and the first time a new email gets your attention (but doesn’t shout for it). The stack allows you to dismiss new emails, or mark them as read or important. The idea is that new emails might fall into the following categories:

  • "Not right now" – A new email will get your attention later. You take notice of its existence now, but don’t have time right now to tend to it. It stays marked as unread, you’ll get back to it later.
  • "This I really have to deal with, later" — If you don’t respond to this email, the world implodes into dark matter, or your head gets torn off by zombie-chinchillas. You mark the email as important, for extra attention, you can leave it marked as unread.
  • "I am bored enough" — An email you deal with right away, either because it’s important or more interesting than what you’re currently doing, or maybe because it’s quicker to reply right now. In those cases, you open the email in your mail client to read it and possibly reply.
  • "OK" — You notice an email and know enough by peeking at it. It can drown in your inbox from here on, you mark it as read.
  • "v14gra on loan" – Something slipped the spam filters. You just want it gone. You hit the delete button and it won’t bother you again.

These are a couple of possible reactions to new emails. By offering the tools to deal with such situations at hand, in the context of these incoming emails, we can pre-sort the stream of mail while we receive it.

The Heap — Important Emails

Important emails are accessible in a separate listThis is where the heap comes in. The heap is an optional second list of emails you can show in the Lion Mail email notifier. It simply shows the important emails in your monitored folders. This way, it offers you a list of things you need to deal with, in essence your to-do list of emails. By putting them into a separate list, we have two overlapping categories of emails you want to deal with. Lion Mail can either display those important emails in a combined list, or using separate tabs for new and important emails. The latter is likely to appeal to David Allen fans, Lion Mail certainly is inspired by some of his ideas.

In the setup you can specify which folders to monitor and wether or not to show important emails

Email Items

The individual email items in the heap or stack offer a couple of options to open emails in your mail client, for marking emails as read and as important, and for deleting it. Needless to say that these buttons operate directly on the email, so the moment you mark an email in Lion Mail, it’ll change in KMail (or any other Akonadi-based email client) as well. When an email doesn’t satisfy the criteria for the heap of stack anymore, it fades out over a period of 5 seconds, so you get some "undo grace-time" if you clicked wrongly. The emails themselves show by default subject, sender, date and flags, you can expand to show some of the body as well. Email items employ a hover interface, when you move the mouse over an email, it reveals three controls as an overlay which offer flagging and trashing an email. Clicking on the icon opens the email in your mail client, you can also drag an email from these lists into your email client or Plasma workspace. I’ve chosen for a hover interface mainly for two reasons: less clicks and more discoverability. The emails don’t have a context menu right now, but there are a couple of useful options we could add there, for example forwarding or replying.

Emails can be sorted using flags directly from the popup

Excerpts — NLP people, listen up!

If someone comes up with a clever and useful implementation for email excerpts, I’m all open. Right now, I’m just showing the first couple of hundred characters in order to not blow the size of the widget beyond what’s reasonable in a small popup. As you can deduct, I’m not the most inspired mind in the world of language processing. In the UI, I’d rather avoid having to use scroll bars inside the expanded email body, as the list already might have scroll-bars. Nested scroll-bars will lead to annoying behaviour for mouse-wheel and flick-scrolling, so that should be avoided. The most elegant thing to do here is excerpting the interesting parts of the email, by skipping empty lines and possibly line-breaks, by removing reply-quoted parts, and so on. K9-Mail (a really good email client for Android) does this quite well, it’s often possible even from one line to judge an email’s content. We can easily fit 5 lines into the expanded email widget, and possibly even more, so I’d expect that with the right algorithm, we could do excellent there. If you’re into that kind of stuff, send me a piece of code that turns an email body (as QString, if you want) into a 200-300 character long excerpt, it should be LGPLed code and you’ll be properly credited. Sounds like a nice small, self-contained hacking project for a fall evening, no?

Otherwise, I wonder if "the other Sebastian"’s recent Nepomuk accomplishments in excerpting documents play into our collective hands, or we’re in his of course. :-)

Emails as first-class citizens in your workspace

There’s if course a lot more in the pipeline. In principle, Lion Mail can hold any email collection, existing folders, but also virtual collections, such as search folders or combinations of multiple folders. Lion Mail represents itself as an icon in the panel’s notification area, you can enable it in the notification area’s settings. It’s also possible to put Lion Mail widgets on the dashboard, desktop or netbook’s new page, you can of course add multiple Lion Mail applets holding different collections one one or different activities, and this way depending on what you are doing, think of showing your work’s inbox in your "work" activity, showing private emails in your "freetime" activity or showing neither in your hacking activity. In Lion Mail itself, that would be very easy to do, It’s built in mind with showing arbitrary sets of emails, the new email and important email queues are just specialized version of a generic email list.Email lists can be put on the desktop, and switched depending on your activity

Drag and drop is also one of the things that got a little bit of attention while developing Lion Mail. You can drag emails from Lion Mail into KMail for example to move or copy them to another folder. Plasma is also receptive to dropping mails (and in the future mail folders) onto the desktop. Lion Mail includes a Plasma widget showing an individual email. It can take different sizes, so you can either have a bunch of small emails floating around, or individual emails with full text on your desktop or dashboard for reference while working, as it often comes handy to have a related email available for a quick check if you’re looking into something.Single emails can be put on the desktop as well, for quick reference

Release plans and test-driving

In its current state, Lion Mail email notifier is already quite usable. The work to make it release-ready consists of completing some features, refreshing of monitored folders directly from the applet, and trashing emails. There’s also some smaller interaction glitches I’ll fix before it can make its way into Plasma cq. Kontact 4.6.0. There’s suspending removing items under your mouse (or finger) so you don’t accidentally click on the wrong email, some display funkiness here and there (spot the lack of space underneath emails in the screenshots), and the excerpts extraction I invited input to above. You’re already most welcome to try it and give feedback. It’s currently located in playground and will eventually move through the kdereview process into one of the released modules — I haven’t figured out which one would be the most suitable exactly. If you want to build it right now, I have to admit that it’s not completely trivial from scratch, as it requires kdelibs and kdepimlibs from trunk. If you have a reasonably recent 4.6 (trunk) snapshot installed, you should be good to go. Lion Mail does not offer the option to configure email accounts, you can do that from KMail2 or akonadiconsole.

Famous last words

The heap and the stack of Lion Mail offer the opportunity to create a more efficient workflow with your emails. By dealing with emails effectively as they come in, but without a context-switch to the full email application, it offers more workflow-based email management. The underlying idea behind Lion Mail is that emails become first-class object in your user experience, to integrate them as artifacts of your interesting information, rather than banning them into a monolithic application like traditional email clients. "Light-weight email work" can be done directly from the workspace, referencing emails in other tasks becomes a lot easier, the traditional email reader still serves as the work horse for most email reading (as opposed to noticing and referencing). Lion Mail provides the usual feature set in a more elegant and context-rich way. It is also heavily optimized for people with larger amounts of emails, and integration these streams of new and interesting emails deeper into the workflow of the user.

Working Upstream.

On the website of an Austrian (no kangaroos!) newspaper, I read an interview with Canonical’s Jono Bacon. In this interview, Jono talks about the process of developing central components of the desktop inside Canonical. The process is basically that Canonical’s design department, Ayatana develops components. When they are finished, they’re offered for inclusion into GNOME, which was not a successful in all cases yet. According to Jono this is "working upstream", explaining that in this context Ayatana is the upstream. GNOME is seen as a provider of components, building blocks for Ubuntu’s user experience.

The definition Jono handles of upstream development is quite different from how it works for me. I can speak of personal and professional experience in this context, as I have been working quite a lot on central components of the Plasma Desktop (and Netbook as well). I have done this work both, as a voluntary contributor in my Free time (pun intended), and continue to do so in my working hours for open-slx. open-slx happens to sell and support Linux deskop operating systems.

Nowadays, many of my contributions to Plasma and KDE in general are paid for by my employer, open-slx. As part of my job, I am allowed and intended to work inside KDE during working hours, this includes "hacking on Plasma stuff" as well as taking on some organizational load, such as working in the release team and the KDE e.V. Board. open-slx’ philosophy behind this is that it is essential to play nicely in the community as a company, and that selling a product which heavily relies on its user experience is made easier, not harder by working directly in the context and infrastructure of the project we intend to merge our creations into. In my case that’s KDE, and especially the Plasma team. This means that I commit my work directly to KDE’s source code repository, that design and technical decisions are being taken in the approriate upstream communities. This can happen for example during sessions at Akademy, at sprints, on IRC and most importantly on mailing lists such as and

The latter two are a nice example for a project I’m currently working on, the Akonadi-based email notification system. During Akademy, I sat together with a bunch of the KDE PIM developers, to design the new email notification system that will likely come along with Plasma and KDE PIM 4.6.0 next January. Over the past weeks, I’ve spent quite some hours on working out the plans. I’ve committed my changes to the code right away to KDE’s SVN to share them with others. Once the code is "good enough", it’ll be submitted for review and inclusion into Plasma or PIM, whatever makes more sense from a packaging point of view. It will be released together with Plasma 4.6 next year and through openSUSE 11.4 will be part of open-slx’s next product, the boxed version of openSUSE. This way, these contributions, the working hours my employer pays for trickle back into our product via downstream projects such as KDE Plasma and PIM teams, and openSUSE. The initial design of the new Plasma email notifications has actually been born during Camp KDE 2009 on Jamaica, but that’s a different story altogether. If you now are interested how that actually looks like, that will be the topic of another entry on this blog.

Let me get this straight, though. It makes sense to provide modifications to the user interface as add-ons that other companies with a similar product don’t ship. Also products based on Free Software need unique selling points in order to make their whole enterprise commercially interesting and viable, and thus make money flow into the development of Free Software.

On the licensing side, this is expressed in making it possible to write proprietary components, for example by using the LGPL license for libraries — Qt, kdelibs and libplasma are all licensed under the LGPL for exactly that reason. Technically, systems such as Plasma’s widgets which can replace any part of the whole Plasma Shell, be it the display of notifications (which Aurelien has actually proven by writing a Plasmoid that displays notifications according to Ayatana style guides), the taskbar, or all kinds of online services. From a branding point of view, the simplest case is probably slapping your branded wallpaper onto the default install. More advanced usages would be a customized Plasma theme, or maybe even "fingerprint animations", that make using your desktop feel a bit more special. For open-slx, Plasma turns out to be an excellent choice of toolkit to build an improved user experience upon, and that is true: we can virtually turn Plasma into any kind of product we like functionally, we can make it behave and look like exactly as we like, and we can maintain a clear separation between aspects we think are the unique selling point of our product, and the contributions we make directly upstream as part of being a good citizen in the KDE community.

The point here is that in order to sustain a Free Software eco-system such as KDE, or maybe GNOME (like in Canonical’s case) you need a healthy balance in your contributions to the upstream community, and your work to differentiate yourself commercially. It’s good practise to make a clear separation between the things you choose to be your USP and your Free Software contributions. Communicating clearly what your contributions are and where you are "commercially sensitive" is both essential: You want to create goodwill among developers that don’t get a paycheque from you (so-called "community support") when you need their help in a context that’s commercially sensitive to you, and which you want to keep separate for licensing and marketing reasons. Moreover, this clear distinction between your proprietary add-ons and your upstream contributions make it clear to customers why to buy your product, and not the competitor’s one.