KDE Commit-Digest
"Lion Mail" is a new Plasmoid that displays information about emails on the Plasma desktop. The general concept is to display certain selected emails, and to notify about new emails under specific conditions (for example, "Show new emails in my 'Private' and 'Work' folder, but only notify me about new ones in the 'Work' folder"). I want to create a flexible way of dealing with emails that does minimal harm to the workflow by giving quick access to interesting new emails. It should be easy to decide for the current user whether to deal with the email right away, to put it aside for reference, or whatever, without doing a "full task switch". Emails should be first class objects on your desktop. Drag-and-drop support for emails is planned as well: it should be natural to just drag-and-drop an email or a folder onto your desktop if you need it for the current task.
Design
Lion Mail consists of three parts: the Akonadi data engine, an email applet, and the Lion Mail container.
The Akonadi data engine provides access to emails and contacts to Plasma applets. The Lion Mail applet uses the data engine to retrieve header information and collections from Akonadi. The data engine loads everything on demand only. The basic idea is that it provides lists of collections, and (for those collections) lists of emails. The same goes for contacts.
 |
The "Email Message" applet displays the contents of an email (sender, subject, recipient, and so on). It can take various forms. A tiny email applet is just one line high, much like an item in a traditional listview, or a menu. The more space the email applet can use, the more information it will show. In Akonadi there's the distinction between the email's envelope for headers and meta information, and the full payload which also includes body and attachments. The "Email Message" applet loads the full body on demand when it's supposed to show it, as body and attachments can be quite large.
Lion Mail is a container that can hold collections. Collections are implemented as Plasma Extenders, so you can tear a conncetion off of Lion Mail and put it somewhere on the desktop. Collections share a configuration (the one from Lion Mail), but are otherwise fairly independent. A collection is usually a set of emails (a folder for example), or an Akonadi query.
 |
Status
With all that said, only the very basics are in place right now. Lion Mail is in a very early and immature state at the present time. It is missing features itself (notifications, for example), but it also depends on Akonadi in two ways: Akonadi doesn't provide fine-grained access to searches yet. It is planned for the future, but not yet there. Then of course, the user's data needs to get into Akonadi first, that means most users will only see Lion Mail working for them when KMail is ported to Akonadi, which is currently planned for the 4.4 release. Mailody by Tom Albers, however, uses Akonadi already, so Lion Mail will work well with it (at least that's the plan).
Future
I also have some ideas for the future (which maybe just means that I'm a slow coder ;-)). First, the user should be able to check email using Lion Mail. Then, I'd like tighter integration of contacts, so you can get quick access to more information about the person you're emailing with. I've already added basic support for contacts to the Akonadi data engine, though it's still pretty rough. Then, I'd like to make Lion Mail fully NEPOMUK aware. Tagging and rating would be first steps, cross-referencing emails ("related emails") and switching shown collections and enabling or disabling notifications based on the current Activiy would be further steps. That way, when you switch to working on some project, the emails and contacts related to that project automatically become available at your fingertips.
Aside from those wild dreams, Lion Mail should still satisfy the use case of "I just want a notification when someone emails me" perfectly well.
First, I'll need to get the basics working though.
