Archive for the ‘Akonadi’ Category
Sunday, June 17th, 2012
In this post, I’ll try to provide an overview of the results of the work we’ve done during the Workspace sprint in Pineda de Mar, Catalunya, Spain. The sprint is still going on, unfortunately I had to leave early to attend a friend’s wedding. Before going into any details, a few thank yous and credits are in place: Aleix Pol and Alex Fiestas for being excellent hosts organising this sprint (including picking this terrific location which allowed us to concentrate 100% on our processes and 0% on the beach), KDE Spain for sponsoring our food, the KDE e.V. (and its donators!) for sponsoring travel expenses and providing organisational backing, Kevin Ottens who took a sizable slice of time out of his vacation account in order to facilitate meetings, enabling group dynamical processes and generally being a good moderator, Björn Balasz for chipping in time and providing his background in psychology and usability and of course open-slx, my awesome employer.
Activities central: One focus that we have been working on in Plasma quite extensively is organising your documents, contacts, applications, files and other digital assets into Activities. Activities provide a contextual way of organising your devices. Activities usually enclose these resources into personal context which might include locations, contacts, documents and any other resource we’re able to express in terms of semantics. (So pretty much all. :))
We’ve identified areas where we can improve the activities workflow. Switching between Activities and getting an overview can surely be improved. There have already been some ideas floating around, and some smaller and larger improvements are in the pipeline to see the light of day in one of our future releases. In some parts, we’re transplanting features we have matured in the Plasma Active user experience into the desktop. The Plasma Way: Share code across devices, investigate workflows across apps and device borders. (So a workflow which we want to enable may actually involve using more than one device — we want to make especially these patterns a lot easier, intuitive and fun to use. There’s a few real challenges in there, although many parts involve someone “just sitting down and doing it”.
Personas: I’ve dedicated a separate blog entry to Carla and Raj, our brand new personas, so I’ll kindly refer you to that.
Social networks and messaging: Carla’s and Raj’s lives involve talking to people across different channels. We want to enable these patterns by providing deep integration of messaging and social networks into the desktop. While we likely will not ever support every single feature of all social networks, we definitely want things like native notifications for messages, and being able to keep tabs on the going ons around you. Technologies we’ve been working on in the part years and which are coming to mature now will be a great help in creating a nice user experience here: Akonadi, Telepathy being at the forefront of double-plus-useful frameworks here.
Along with the integration of more social services into the workspace, we also want to enable cross-device workflows using online services. Examples for getting your data across devices are ownCloud, but also commercial services like FlickR. I think we are in the position to put Free software solutions first, but not excluding proprietary services, but enabling Carla and Raj to mix and mesh whatever they uses. In this, we need to pick up the user where he or she is now. We’re not going to switch users to Free software users if we require social disruption in their lives. :)
Something I found particularly exciting was the call by a few participants to reinvigorate Project Silk. The idea is to make the web, web apps, -applications and -services first class citizens in the desktop. This can range from the introduction of a site-specific browser to deeper integration of online content and services: think of FlickR integration in Gwenview, caching data from online sources, providing native UIs for services that are otherwise a bit cumbersome to use, and much, much more. I’m surely hoping we’ll see a surge of improvements in this area. I’m also happy that Richard and I documented our ideas quite well when we came up with them in 2009 at the Desktop Summit in Gran Canaria (coincidentally also Spain, at least technically ;-)).
There’s almost too much exciting new ideas that it’s hard to report about all of it without choking your feedreaders or webbrowsers, so I’ll just mention a few more telegramme-style. Feel free to ask in the comments if you have specific questions, or just head over to the firstname.lastname@example.org mailinglist where you can discuss with the whole team involved.
- As base for identifying needed improvements, we will concentrate our thinking on which workflows we can enable for users. This first line of identification will be thought about without a specific device in mind. Much more so, workflow can and often do include different devices. We want this to be at the heart of our designs.
- Virtual desktop will remain what they are, orthogonal to the principle of Activities, We do not plan any sweeping changes here, in order not to break engrained workflows. Nepomuk synchronisation across devices is still a very challenging problem. It needs more design and research work to define an achievable scope.
- We’ve proposed a few changes to KDE’s release rythms, basically decoupling the releases of workspaces, applications and (in the future) KDE Frameworks. This is basically a continuation of KDE’s effort to implement branding closer aligned to how we work and what we produce; currently under discussion.
- Notifications will likely receive a rework in order to make them more activity aware, and to display insensitive information on a lock screen, just to name two examples.
- Everybody agreed that stability and quality are key for users. We will avoid disruptive changes, but concentrate on making existing tools better, and new features not get in the way of existing workflows. A few changes in our processes have also been planned,
- Clemens of Blue Systems attends the sprint as well, it’s good to see new faces participating and supporting KDE. We’ve had very interesting conversations about all kinds of topics.
- Maybe the most important thing was the sharing of the Plasma vision with a wider team of contributors. It strikes that Plasma lately has been moving so incredibly fast that we built up a backlog of communication, some of which we managed to knock down in the past days, but it surely will take some time until all ideas, concepts and processes are ingrained into everybody’s brains. The first steps for this have been taken, however.
As you can see, that’s a lot of stuff we have carved in sand in the past days. It will need refinement, and consolidation, more design, ungodly amounts of hacking and surely won’t all be implemented in a whim. It does however give everyone a good idea where we’re going, and what the steps into that direction are. Exciting times ahead. If you’re looking for more sprint results, I’d also read Marco’s blog about it.
Saying good bye was relatively easy this time around, as most people attending the sprint will also be at Akademy, which starts in two weeks in Talinn, Estland. The next Plasma sprint is planned in September in Switzerland. The plan is to mostly work on libplasma2, QtQuick2 and Frameworks 5 in order to technically pave the way into the future of the Linux workspaces.
Wednesday, September 22nd, 2010
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.
Complex 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 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
This 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.
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.
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.
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.
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.
Thursday, August 26th, 2010
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.
A 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 freedesktop.org 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.
Many 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.
The 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.
You 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
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.
Unfortunately, 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 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…
Akonadi 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.