The Road to KDE Frameworks 5 and Plasma 2

KDE’s Next Generation user interfaces will run on top of Qt5, on Linux, they will run atop Wayland or Xorg as display server. The user interfaces move away from widget-based X11 rendering to OpenGL. Monolithic libraries are being split up, interdependencies removed and portability and dependencies cut by stronger modularization.

For users, this means higher quality graphics, more organic user interfaces and availability of applications on a wider range of devices.
Developers will find an extensive archive of high-quality, libraries and solutions on top of Qt. Complex problems and a high-level of integration between apps and the workspace allow easy creation of portable, high-quality applications.

The projects to achieve this goal are KDE Frameworks 5 and Plasma 2. In this article, you’ll learn about the reasons for this migration and the status of the individual steps to be taken.

As this article is going to be a bit long, due to its level of detail, you can just skip to the end of every subsection to get the executive summary. Also, I would like to thank Blue Systems for their sponsoring of a lot of the work that is going into the future of KDE’s products, among which, mine.

Status Frameworks 5

Development of KDE’s Frameworks5, which focuses on modularization of APIs currently contained in kdelibs and kde-runtime, loosening its internal structure and making it possible to only use specific parts by splitting it into individual libraries and solutions.

The entire work to be done for Frameworks 5.0 is split into 7 topics. Three of these “Epics” are done:

  • Initial communication and documentation (Kevin Ottens),
  • Merging of code into Qt 5.0 (David Faure)
  • Reduction of duplication with Qt by removing classes and using their Qt alternatives (Stephen Kelly)

Four Epics are currently work in progress, three of them are monstrous:

  • Build system (Alex Neundorf, Stephen Kelly)
    • CMake (upstreaming some stuff, modularization, porting)
    • Modularization of CMake KDE settings (work in progress)
    • Modularization of macros
    • Review and inventarize Find* CMake modules
  • kdelibs cleanups (David Faure)
    This is a large Epic, containing many bite-sized tasks. Roughly 50% of them are done, 37 tasks remain open and 7 are being worked on, an extensive list is on the wiki.
  • Qt 5.1 merging (David Faure)
    This is the list of things that we haven’t been able to merge upstream into Qt 5.0, so we hope we can upstream as much as possible into Qt 5.1. This can potentially cause timing problems, if we can’t get all the necessary things we need into Qt 5.1. 9 tasks are work in progress by David Faure, Thiago Maciera, Richard Moore and others. 52 tasks are on the todo list, most of them currently unclaimed.
  • Splitting kdelibs (blocked) (Kevin Ottens)
    Another large Epic, in bigger chunks, meaning going through all libraries one by one, porting their build system to the changes in Frameworks5, cut out certain library dependencies and changing the translation system. 13 tasks are done, 12 work in progress and 8 on the todo list, not all of them assigned.
    An extensive list of libraries and their status can be found on the wiki.

Frameworks 5 currently compiles on top of Qt 5.0 and basic system services run (kdeinit5), although not all of its dependencies have been ported to Qt 5. Work on Frameworks5 is ongoing, so it is currently quite a moving target, and will remain so for a while.

Plasma and KWin Direction

An architecture based on Qt5 and Wayland makes it possible to use a more modern graphics stack, which means moving from X11-based rendering to OpenGL graphics rendering. QtQuick2 (which is the QtQuick shipped with Qt5) makes it possible to offer a very nice and extensible development API, while using the full power of the graphics hardware to produce excellent visual possibilites. Plasma offers development APIs that make it easy to create well-integrated applications as well as workspaces that are flexible, extensible and fully featured on top of QtQuick, and in the future QtQuick2.

As KDE moves forward towards Frameworks5, Plasma is taking the opportunity of the source and binary compatibility break of Qt5 to do necessary updates to its architecture. The goal is to have a leaner Plasma Development API and depdendency chain and achieve a better user- and developer experience by moving the UI fully to Plasma Quick, which is QtQuick plus a number of integration components for theming, compositor interaction, internationalization, data access and sharing, configuration, hardware, etc..

This constitutes a major refactoring of the Plasma libraries and components. First, their UI needs to be done in QML. This effort of porting workspace components to QML is already well underway. Second, the Plasma library and runtime components need to be ported from the QGraphicsView-based canvas to QML. This means cutting out dependencies on classes such as QGraphicsItem and QGraphicsWidget to their equivalent in QML. In the case of painting and layouting code, it means porting this code to QML.

Detailed Status Plasma Framework

The first bigger set of tasks is done:

  • API changes have been made in libplasma2 (done)
  • De-QGraphicsViewification of libplasma2 (done)

The open tasks are:

  • Remaining libplasma2 design tasks
    • Out-of-process dataengines
    • Dataengines as models
    • More fine-grained data retention in dataengines
    • Improved remote widgets
    • Change libplasma2 directory structure to reflect Frameworks5 policies
  • Create a scenegraph-based shell, make it load a QtQuick2Corona, Containments and Applets
  • Port QML Scriptengine to QtQuick2
  • Port scriptengine from QScriptEngine to QDeclarativeEngine
  • Remove dependency on graphics backend (QGraphicsView, or scenegraph) (Marco Martin)
  • Port imports to QtQuick2
    • Plasma Core (containing Theme, FrameSvg, DataSource, etc.)
    • Plasma Components (containing a basic QtQuick widget set)
    • QtExtras (containing components missing in Qt, such as MouseEventListener)
    • PlasmaExtras (containing additional UI widgets for better integration, such as animations, text layout helpers, Share-like-connect integration, etc.)
  • Making scriptengines (such as the Python scriptengine) only export QObject-deriven classes to the QML runtime (needs investigation right now)
  • Port of widgets away from QGraphics*, also necessary for some QML code

Plans for KWin Plasma Compositor

Plasma Compositor refers, in a Wayland world, to the compositor used for Plasma workspaces, which is essentially KWin in disguise as Wayland compositor.
In KWin, we benefit from an ongoing effort to modularize and clean it up architecturally. For most of its UI, KWin already supports QML (Window decorations, tabswitcher, etc.). Some mechanisms which currenty work through XAtoms will need to be ported, the API impact of that will likely be quite limited for application developers.
The strategy for KWin is to port KWin to Qt 5, then make it possible to run KWin outside of an X server on top of KMS, using the graphics hardware more directly. The next step is to use KWin as compositor for Wayland display servers. The dependency of X11 can be removed once it is not needed anymore to provide compatibility with X11 applications, or can possibly be made optional.
Milestones for KWin (Martin Graesslin) (updated with further clarifications, thanks Martin):

  1. KWin on Qt5 (work in progress, planned for 4.11): KWin will not depend on Qt 5 as of 4.11. The idea is to have KWin in a state that we could compile KWin with Qt 5/KF 5. But as it is unlikely that KF 5 will be allowed dependency for 4.11, we will not see a KWin on top of Qt 5 even if we achieve that goal. It’s a weak goal as we cannot release on it anyway.
  2. on top of KMS (planned for 4.11): KWin in 4.11 will still run on top of the X-Server. This is mostly about adding a proof-of-concept. Whether that will be merged into 4.11 and compilation enabled will be seen once the code has been written. So in this case it will at most be an additional very hidden (env variable) mode for testing.
  3. KWin as Wayland compositor (planned for 4.12): Again only as addition. As of 4.12 we will still be targetting X-Server as default. If we succeed we might add an option. But this pretty much depends on the state of Qt 5/KF 5 and QtCompositor. If any of those dependencies is not ready to depend on, the code might exist, but will not be released.
  4. no X11 dependency (planned for the distant future): There are no plans to drop X11 support. But we want to have the possibility to build a KWin without X for new targets like Plasma Active. For the desktop there are no such plans.

Plasma Workspaces

The porting strategy of the workspaces is to port plasmoids and containments to QML, in order to make them ready to run on top of the new infrastructure. In the case of C++ and Python, Ruby, JavaScript and “Web API” applets, it means rewriting them in QML. For portability and maintainability reasons, pure QML widgets are preferred. For some complex use cases, that can not be easily done in QML, we ship a combined C++ QML applet. For Plasma2, the only way to do the UI is using QML. QGraphicsWidget based Uis will not be supported anymore.

Once we have a working libplasma2 and a useful set of QML Plasmoids, we can think of running an entire workspace in QML and on top of QtQuick2, either on top of X11, or with KWin’s plans in mind, on Wayland.

Porting status of important widgets to QML / Plasma Quick needed for the workspace:

  • Taskbar (close to first review, target: 4.11) (Eike Hein)
  • Folderview (work in progress) (Ignat Semenov)
  • Desktop containment (second revision close to review, target: 4.11) (Sebastian Kügler)
  • Calendar (work in progress, target: 4.11) (Davide Bettio, Sebastian Kügler)
  • Kickoff (about to be merged into master, target: 4.11)
  • KRunner (work in progress, target: 4.11) Aaron Seigo, Aleix Pol
  • Done: System tray, pager, notifications, device notifier, battery, lock/logout, weather, Wallpaper, Containment support
  • Open:
    • Digital Clock
    • Icon
    • Picture Frame
    • others from kdeplasma-addons
    • and more (see wiki)


KDE’s Framework 5 project is well underway. It will allow us to move to a more modern graphics rendering engine, make our development platform more portable, and make it easier to reuse solutions KDE has built. The work does not happen by itself, however, yet it is time-critical. With Qt5.0 being released, 3rd parties are porting their code already. These people will only consider using KDE’s technologies if they are actually available — and that means we need a Frameworks 5 release.

So is this going to be KDE 5? The answer to this question is still “No!”, for a number of reasons:

  • KDE is the community, not the software
  • Frameworks 5, apps and the Plasma workspaces are not one singular entity. These parts are only released together (which might change in the future), and cobbling them up under one name really is really not helpful. (3rd party developers will think we’re only targeting Plasma workspaces, Plasma users will think you’ll only be able to run “KDE apps”, potential users of applications will assume that you can only use them inside Plasma workspaces — all of them untrue, all of them taken right out of my daily experience)
  • Within the Plasma team, we tend to use the abbreviation PW2 to refer to the next generation of Plasma workspaces. It stands for Plasma Workspaces 2, and it will probably be named differently in the future.

So, now you’re fully up to date on the status, isn’t it time to get cracking?

Randa Meetings 2012: The Future of QGraphicsView in Plasma

I’m on my way back from the Randa Meetings, where a few teams in KDE came together to collaborate on the next steps in their respective subprojects. I’ll post this to my blog after arrival, but as I’ve got some time to kill here in Basel, Switzerland, close to the German border, I decided to recap what we’ve been up to in the past days. I’ll concentrate on what the Plasma team has been working on. Present were Marco, Aaron, Afiestas, Giorgos, Antonis and myself. Giorgos and Antonis are still relatively new to the Plasma team, they concentrate on on making Plasmate rock, but have also done some excellent work this week on libplasma2. I’m happy to see the influx of enthusiast and skilled new developers in the team, as that reduces the busnumber and makes it easier to achieve our audacious goals.

Peak up to the glacier from Randa
Speaking of goals, we came to Randa with the plan to achieve a critical mass towards libplasma2. But what is libplasma2 exactly? Well, while we had some plans where to go with it, there were still a few items unclear — but not anymore! One of the big ticket items was the future of QGraphicsView in Plasma. QGraphicsView had been introduced in Qt 4.1. It’s basically a canvas on steroids, that gained features to create a fluid, widget-based UI using it. In Qt4, QtQuick uses QGraphicsView as its rendering backend. QGraphicsView is heavily based on QPainter, and employs a procedural way to rendering the UI. In Qt5 and QtQuick2, graphical display is supposed to move to an OpenGL scenegraph, making it possible to move much of the work involved to display a UI into hardware, so your GPU can do its magic with your UI. The benefit for the user is mainly that we’re able to have a much better performing rendering engine underneath (so smoother graphics), and more CPU time left to do the real work of your application. (One side effect will likely also be that we save a bit of power on mobile devices, as the GPU is much more efficient in doing these tasks – it has been optimized for it. (Experts say that the saving is in the range of an order of magnitude. Wether or not it will be noticeable to the user in the end, we’ll have to see later.)

As the OpenGL-scenegraph-based rendering is an entirely different paradigm compared to the procedural QGraphicsView, we have to rethink our use of QGraphicsView. Unfortunately, QGraphicsView is deeply ingrained into Plasma’s architecture. Even more unfortunate is that it’s not as bugfree as we’d like it to be, in fact much of the occasional rendering glitches you sometimes see in Plasma-based UIs are caused by QGraphicsView problems. Moving away from QGV and towards scenegraph is likely to solve this whole class of problems.

So one thing is clear, we want to move towards scenegraph. But what about all the old, QGraphicsView-based code? Well, we already started moving components of Plasma Desktop one by one to QML. This has begun with Plasma Workspaces 4.8, a lot more has moved in the 4.9 cycle, and yet another batch will move with 4.10, which will be released in January 2013. Our credo has been that we want to ship feature-equivalent ports, in order to keep the impact for the user as minimal as possible. There will be a point, however, when we will have to remove support for QGraphicsView in libplasma, and that will likely be libplasma2. We expect this work to take still more than a year, so also third party developers get ample time to move their code to the (much nicer) QML way of doing UI. But why not keep support for QGraphicsView? Well, it’s not that easy, as scenegraph and QGV are due to their respective paradigms more or less mutually exclusive. We’ve spent quite some time trying to come up with solutions that guarantee maximum amount of backwards compatibility, but we also had to ask ourselves if we have the manpower to implement and maintain workarounds for the incompatibilities between scenegraph and QGV. Moreover, what would the impact on our APIs and our code be? the tradeoffs were quite horrific, so in the end we decided to bite the bullet, and remove QGV from the frameworks5 branch. But what will Plasma2 with out QGraphicsView become? What we came up with is actually a very neat and clean approach: Our classes that currently manage the workspace (Corona, Containment, Applet) will become abstract managers that concert how components work together. Containments and Applets will have their UI written in QML (so we can do the rendering in the scenegraph, thus in the graphics hardware). They are extensible through C++ and various scripting languages that have bindings for Qt. This way, you can choose to implement the business logic in your favourite procedural language (C++, Python, Ruby, QtScript, etc.) and do the UI in a declarative way. Things like theming, localization, distribution, and all that will still be offered by the platform.

Clouds descending into Randa

In Marco’s preliminary branch, where he removed support for QGraphicsView from libplasma2, the result is quite spectacular. The library is already about 30% smaller, and will likely lose another big chunk of code. That means more maintainability, a smaller memory and disk footprint and faster startup. As the functionality of QGraphicsView is more or less a subset of what we can do with QML, it’s not any less powerful or flexible. Just smaller, leaner and meaner (and also a bit easier to grok for developers using our APIs).

As you can see, we have been quite productive during this year’s sprint in Randa, and the above is only one part of what we’ve worked on. We’ve also made quite a dent into our TODO list for the KDE Frameworks 5 port, reviewed lots of patches, fixed bugs left and right, made existing code faster, and caught up with each other on various side projects. This all would not have been possible without the sponsors of the event, and the 287 people who donated through our fundraiser campaign to make this great event in a scenic location possible. Thank you all!

Demystifying Akonadi.

The exotic-sounding ‘Akonadi’ refers to both a mythological figure and the KDE platform’s central information framework. This article will dispel some of the mystery about how Akonadi will improve performance and integration, and how it is being rolled out into KDE applications. I’ll also provide some insight how the technology works, and what will become possible with this new PIM framework.

Many people have been asking what the status of the new, Akonadi-based Kontact Groupware suite is. As I’ve been working closely with the PIM hackers, I thought I’d give my readers a heads-up on what’s going on and what to expect. In this article, I will often take KMail as an example for the port, but similar things apply to the other PIM applications that form the Kontact suite as well.

The What & How?

I’m sure many of you haven’t heard the name Akonadi yet, so let me quickly explain what it is. Let’s get technical.

Akonadi is a groupware cache that runs on the local machine, a shared data store for all your personal informatio. Akonadi offers a unified API to receive and synchronise data with groupware, email servers or other online services. Agents called “resources” are responsible for communicating with the remote service, say your email server. These resources run out-of-process and communicate via separate control and data channels with the mothership (your local Akonadi). Resources are easy to implement and can interface any data source with Akonadi, be it your local calendar file, your companies groupware, email servers or address directories, or anything else you can come up with. More on that specifically later.

The Akonadi groupware cacheA common misunderstanding is that Akonadi is some sort of groupware server. In fact, Akonadi does not store any data itself, but just provides a common means to access data to your local applications.

So Akonadi does not store user data, it caches it. The user data is still stored in the traditional formats, be it on an online server (for example IMAP) or local files (ICAL calendar files). Locally, Akonadi provides a cache to speed up access and to make collections (email folders, for example) and their items available offline. To allow Akonadi to work on both powerful desktops and lean mobile devices, Akonadi can use different databases for its cache. Currently, the most complete backing store for Akonadi is MySQL, but PostGreSQL and sqlite backends are also available. In the case of MySQL, the database is started and handled by Akonadi itself, using a local socket, and no network access. This is intentional, for speed and security, since Akonadi’s database is really only a detail of the implementation.

The storage concept of Akonadi is straightforward. The team looked at many types of PIM data and found that items stored in folders are common to all of them. In Akonadi, Items represent mails, contacts or other individual pieces of data Folders are generally referred to as Collections, which can contain other Collections. Items themselves carry a type (using the standard mimetype definitions), metadata and the actual data payload. Items can be identified by URLs. This URL is of course only valid locally, but it allows passing references to Akonadi items and collections around without copying the actual data. This makes Drag and Drop across applications (or in my favourite case, from the email notifier in Plasma into KMail) very easy. The receiving application can use any Akonadi client library to take the Akonadi URL and fetch its headers, or data. Akonadi Items may be retrieved partially, so if an app wants tod display a list of emails, it doesn’t have to copy around the whole inbox, attachments and all, but can just ask for a list of headers of those emails.

In order to access the Akonadi cache, and more importantly the underlying data, you can use one of the Akonadi access libraries. To my knowledge, there are Akonadi bindings for GTK+, Python and the Qt-style Akonadi classes already available. As you can see in the diagram, the design allows for different ways of accessing the Akonadi data, in the diagram the examples are called the “GNOME API” and “KDE API”.

As you’d expect, I’ve mostly worked with the KDE API, which you can find in kdepimlibs. This Qt-style library has been available for a couple of KDE Platform releases already, and is being further enhanced for more coding convenience, stability and performance all the time. There is a bunch of job classes, that allow for async access to Akonadi items. Relatively new are the MVC classes, notably EntityTreeModel and friends. The ETM and its friends and API sugar around it also provide async access to Akonadi data as well, and also allow for easier sorting, querying and filtering of all the data and metadata. Metadata handling is another very interesting aspect of Akonadi in itself, more on that later, as well.

Current Status

Plasma's calendar displaying calendaring info from AkonadiMany people are interested in the current status of Kontact’s Akonadi port. Initially, KDE had planned to release the new Kontact along with the rest of the KDE Applications 4.5. This did not quite work out, so we pushed the release back a bit, and are planning to release it along with one of the 4.5.x updates. The current plan is to release the Akonadi port of Kontact still this year. In contrast to our usual releases, this step is a bit different. Since PIM data is critically important, we are extending the beta phase until the Akonadi port of Kontact passes a much wider range of QA tests. When we are able to release depends a lot on the feedback we get from users. We are therefore making available monthly beta releases of the new Kontact suite. Data loss in this late phase of the port is extremely unlikely, and we made sure that trying the new Kontact doesn’t mean you must now also do the switch. You can in fact just reinstall the old one and use that again, since separate configuration files are used.

KAddressBook is already available in its Akonadi incarnationThe traditional Kontact, is of course still fully usable and we currently recommend this to end users. Kontact 4.4 is still actively maintained and supported, and is shipped by distributions along with KDE 4.5.0, so the current stable Kontact is 4.4.5. We did ship a new release of kdepimlibs, which are tested with Kontact 4.4.5 and are the basis for Kontact2 as well.

For normal workloads, KMail2 which is the heart of Kontact’s Mail component is already pretty usable. The focus of the stabilization and improvement efforts currently lies in the complex use cases common to hackers and email power users, such a different, high-volume email accounts, many large folders and a paranoid bunch of identities. Another area of focus is the migration of data, including the possibility to rollback to your “traditional” Kontact if you are not satisfied with the quality yet (please don’t forget to file bugs, so we can take proper care of those nasty insects).


Kontact2 only reads Kontact1’s configuration, but doesn’t change the original copy. Instead, a new configuration file derived from your old one will be used. So when first starting Kontact2, your “old” configuration, account setup, identities and filtering rules will be imported. KMail2 will also import locally cached emails, so you don’t have to download them all again. In the current state, user feedback from migration and usage is extremely valuable to the developers, so please give the next beta a whirl and report back to us, so we can improve on your experience. Of course, there are tools for importing and exporting data. During the migration, Kontact2 uses Kontact1’s existing downloaded email, so a lengthy re-download for offline reading is unnecessary.

If you’re not yet happy with the new Kontact, you can switch back to the old one, by re-installing the 4.4 Kontact.

What will KMail2 look like?

This might come as a little surprise to some, but in the initial version of KMail2, you won’t notice many differences to the traditional KMail1. This has a number of reasons: First of all, KMail’s UI is the result of years of polishing by the developers and a lot of feedback by the community. This won’t be thrown away for something that’s novel and cool, but might not satisfy most users. So KMail 2 will be a very straightforward port of KMail1, the UI will be mostly the same, while the underlying technology has changed completely. In the porting process to Akonadi, most of KMail1’s familiar UI has been kept.

The Akonadi-based Kontact betaYou might have noticed the first parts of KMail1 being converted. That is to say that the Kontact developers have worked towards the Akonadi port of KMail. The first, and actually one of the most central parts of KMail has already been introduced a while ago: the new listview. This listview is a rework of KMail’s list of messages to use the underlying Model-View-Controller design patterns that match Akonadi well. In Kontact 4.4, Kontact’s address book has been switched to use Akonadi. This first step in the migration was a bit painful, since it involved introducing a new infrastructure below applications that you use daily, and which you rely upon. The new possibilities are already making their way to the end users’ systems, for example in the calendar integration with the Plasma Desktop, which you can see in the screenshot. By clicking on the clock, you get the Plasma calendar which shows you your daily events. In the sceenshot, you can see the new version of KMail. As I’m using a full-HD display, I’ve enabled the widescreen layout of KMail. This makes it possible to see the whole email and a long enough list of others at once. A nice touch, which has been available for ages in KMail — just in case you wondered.

… but why the port then?

Simply put, traditional email clients don’t satisfy today’s expectations and work flows around personal data. Well, this of course needs some explanation: Already in times when KDE 3 was state-of-the-art, we noticed that more and more applications became interested in PIM data. Popular examples are Kopete, the instant messenger which held its own list of contacts, data which is mostly duplicated, including the inefficiency and maintenance nightmare you’re facing when you duplicate frequently changing information. So you want some kind of interface for contacts, and it should be something service-like, after all, you don’t want to run a seemingly unrelated application(your address book), just to get some more rich information about your chat contacts. Then, there’s of course my favourite example: Email monitoring. In essence, a full-fledged email client is a bit of an overkill, if you just want to know if there’s new email in your inbox. On of those overkill aspects is performance, or rather resource consumption. The solution to this is of course to share all this data. By using one central storage, and an easy to use access layer we can share the data across applications, and enable applications to make use of already available personal data. Enter Akonadi.

Akonadi has been built with performance and memory consumption in mind. Will Stephenson has put this very nicely: “In the 2.0 <= KDE <= 4.4 days, each program loaded the entire address book, calendars, and more specialised stuff like email, RSS feeds, and IM chat logs into its memory, so memory usage for PIM data increased linearly with the number of PIM apps running. Same goes for non-PIM apps using PIM data (the Kickoff menu's contact search data, Konqueror's Copy To IM Contact feature). Because Kontact is just a shell for KMail, KAddressbook, KOrganizer etc, it caused the same memory multiplication even though it's all one process.

With the Akonadi design, only the Akonadi process loads all the data into memory. Each PIM app then displays a portion of that data as it needs it, so the amount of extra resources taken by each extra PIM app is smaller, and the initial amount of memory used by each app is less. It should also provide extra stability, because each app no longer has to maintain its own data storage infrastructure, with all the caching, integrity and performance gotchas that keep computing science graduates employed.

Plasma’s new email notifier

Plasma's Email Notifier (alpha version)During Akademy, I’ve picked up the work on Lion Mail again. It is not quite done yet, but already looking very good. I’m nearing feature completion for a first release now, so I’m almost sure it will become part of Plasma 4.6 in January, currently it’s in alpha state but quite fun already. Interested users can of course check out the source from SVN, it’s currently located in playground unti the code is ready for review by my eagle-eyed fellow hackers. Lion Mail is a set of Plasma widgets that can be used to display and manipulate emails in Plasma. In Tampere, Finland, during Akademy, I’ve discussed design and workflow of email notifications with a lot of people, after that I sat down for some serious hacking and have already implement most of what I would like to see, email-wise, in Plasma 4.6. The main goal is to be non-intrusive, and making it as easy as possible to manage your email in your daily workflow. The email notifier provides a queue of your emails, but does so without the need to switch to the full-blown KMail, so no full context / attention switch is needed if you just quickly want to see what’s going on in your inbox.

The new email notifier sits, as you might expect, in your panel’s notification area. It’s hidden by default, but becomes visible when there are new emails in your inbox. When you click on it, you get a list of your new messages. Those messages are expandable, so you can peek into the email to quickly judge if it’s something you want to act upon right away, or not. The individual messages are interactive. When hovered with the mouse, four buttons overlay the email. These buttons allow you to mark an email as read, or important (and of course remove those flags). Disappearing emails slowly fade out, so you have a couple of seconds to undo your action before the list is cleaned up.

You can choose to display new email in arbitrary foldersUnfortunately, most normal email notifiers are pretty useless for high-volume emailers, especially if you use server-side filtering (which you should because it’s much more convenient when using multiple clients, especially mobile ones). In my case, I have about 60 folders, on3 different email accounts (work-work, private, gmail). Emails are filtered before they reach the client. I am personally far less interested in new emails in all folders called “inbox”. The Plasma email notifier allows you to choose the folder you want it to monitor. You can also set up multiple folders. As a nice extra, you can choose to also display emails marked as important, either merged or in a separate list (actually, the latter is not implemented yet, but on my short-term TODO list :-)). Emails are draggable, so you can drag an email from the email notifier into a folder in KMail2 if you want to copy or move it there. As I mentioned before, we’re not actually dragging the email around, but an Akonadi reference as a URL. This is fully transparent between applications, and even across toolkit and access libraries. I’ve also written a full-fledged single email Plasmoid, which allows you to put individual emails on your desktop (or dashboard) for quick reference. Just drag the email from the list onto your desktop, and it’ll appear as Plasma widget there, expandable, with HTML if you’re into that. The missing bits are rather overseeable at this point: clearing the list, separate list for important emails, refreshing logic for individual folders and queuing the re-jigging of the list until the mouse moves out, so items don’t change under your mouse while clicking on them. Not just minor bugfixes, but at the current pace, also not a lot of work left to do.


As you can imagine, the email notifier’s design suits itself very well for PUSH IMAP. PUSH IMAP means that instead of checking in intervals for new email, the server notifies your client when a new email comes in. This means less useless mail checks and more importantly instant notification when a new email arrives. With “instant” I mean within a couple of seconds. In my tests, it took between 3 and 17 seconds from pushing the “Send” button on one machine until the email showed up in the email notifier. That’s pretty neat compared to checking your email every 30 minutes or so. So it’s all the more important that new email notifications become too annoying, hence the non-intrusive approach to the UI. PUSH IMAP is currently only enabled for the inbox folder of a given IMAP account, and of course your server needs to support it. The first email received in Lion Mail using PUSH IMAP

Kontact Mobile

The migration of the desktop version of Kontact is another big step in Akonadi’s existence. Akonadi has its uses outside of Kontact on the desktop as well. The new Kontact Mobile suite builds on top of Akonadi as well, but offers a completely different UI, optimized for smartphones and touch-screen devices. Kontact mobile is part of the upcoming Kontact suite as well. The infrastructure is this way shared across the device spectrum while the user interface is optimized for a certain device and use case. Akonadi does the hard work of talking to all kinds of groupware servers in the background, and caching of this data if you want to make it available on the go. The Dot has an excellent article about Kontact mobile, including a cool screencast.

Beyond Groupware – Akonadi and the Social-Semantic Desktop

The new email notifier is a good example what Akonadi makes possible in the near future, but there are more things brewing in the kitchen. As Akonadi is a generic cache, it comes handy in a much wider number of use cases. In the future, Akonadi can take care of managing and caching all kinds of interesting data, as you can stuff into it what you want. One interesting case is managing your online photo collection. Akonadi can provide standardised photo streams locally on your machine which are backed up by online services. In the same vain, microblogging can be handled through Akonadi, free caching, searchability and semantic linking to your contact are made very easy this way. There is actually already a microblog resource for Akonadi available, I’ve heard rumours of a FlickR one as well…

Emails now also in the desktop searchAkonadi plugs into the Nepomuk semantic framework for its indexing and searching needs. Items in Akonadi are therefore magically available for applications using Nepomuk to query and display data. Tags and other metadata is shared across the desktop, arbitrary items can be linked semantically (think emails and attachments linked to contacts in your address book). Akonadi in Kontact does not only mean that Akonadi is coming to full bloom, but also the semantic desktop built on top of Nepomuk. One nice example is shown in the screenshot, where the KRunner mini-commandline (hit ALT+F2!) also finds emails now. Part of the semantic desktop are also the Activities, which provide context to applications. You can think of ‘context’ as a project your working on, your current location, and many other “metadata” of your workflow. One features of Lion Mail which has been part of its idea from the beginning is showing different sets of emails per activity, the email notifier is built with activities in mind.

Plasma’s dataengines provide another fantastic opportunity for Akonadi to shine. The Plasma team is working on a generic cache for data supplied by dataengines, the idea is to transparently allow caching of arbitrary data from dataengines, so offline usage becomes completely transparent for many Plasma widgets. Akonadi forms one of the cornerstones of Project Silk which aims at deeper integration of online services and content into the user experience.


With all the above in mind, there’s little less than a revolution going on in the groupware area. Akonadi matures further and makes possible a full-fledged groupware client in the form of Kontact, with excellent scalability and extensibility. Akonadi is built with a whole spectrum of target devices in mind, which shows in the Kontact Mobile suite running successfully on a N900. With more applications being available in their Akonadi versions, Akonadi will become a lot more useful, and enhance many other applications in the process. Akonadi also allows for a better user experience around email and calendaring in the primary workspace. Groupware is becoming a generic service on the local client. The upcoming new Kontact groupware suite is only the tip of the iceberg of what’s coming thanks to Akonadi. Quite inspiring, isn’t it?

Special thanks go to Will Stephenson for proof-reading the article.