Richard Moore und ich haben das Webslice Applet auf der Akademy 2009 in Akademy geplant, richmoore hat dann einen Prototypen geschrieben, den ich in ein einfaches Plasma Widget umgesetzt habe. Seit dem ersten Release zusammen mit 4.4 hat sich allerdings wenig dran getan. Es funktioniert im Prinzip recht einfach: Wir laden eine Website in einem Webkit Widget (auf der Plasma Canvas), blenden die Scrollbalken aus, scrollen an die richtige Stelle (zur Geometrie einzelner Element kann man Webkit befragen) und zoomen soweit ein oder aus, dass der Ausschnitt in’s Widget passt. Das funktionierte so recht gut, allerdings blieben zwei Probleme: Das Vergrössern bzw. Verkleinern des Widgets war viel zu langsam, und dadurch nicht flüssig genug, und die Auswahl des Ausschnitts war alles andere als intuitiv — man musste den richtigen CSS2 Selector eingeben, diesen also erst aus dem Quellcode der Website puhlen.

Gestern abend habe ich eine Reihe Änderungen eingepflegt, die hier deutliche Verbesserung bringen. Nach Review auf der plasma-devel Mailingliste habe ich diese Änderungen auch in den 4.6 Zweig committet, d.h. dass sie mit 4.6.1 in ca. einem Monat zur Verfügung stehen werden. (Oder ihr besorgt euch den Code aus KDE’s SVN bzw. Git, unter kdeplasma-addons/applets/webslice.) Schau’n wir mal, was ich so geändert habe…

Performance

Vor allem das Vergrössern und Verkleinern des Widgets machte eigentlich kaum Spass. Das Web-Scheibchen Widget benutzt eine Webkit View, und zeigt die Seite an einer bestimmten Position an, mit einem zur Plasmoidgrösse passendem Zoomfaktor. Soweit, so gut. Dem Performanceproblem lag zugrunde, dass das Widget während dem Andern seiner Grösse so viele Resize Events abfing, dass es mit dem Zoomen und Positionieren nicht nachkam, und diese sich aufstauten. Dem habe ich Abhilfe verschafft erstmal die Codepfade, die zum diesen “resize events” führen aufgeräumt habe, sodass dieser Vorgang nur stattfindet, wenn es wirklich nötig ist. Dann habe ich mittels eines QTimers verschiedene, schnell aufeinanderfolgende Events zusammengefasst. Beim Zoomen des Widgets war auch noch so Einiges drin, wenn man die Backingstore zeitweise einfriert, und das komplette Neurendern der Seite dann um einige Millisekunden verzögert. Zusammen damit habe ich auch die Seitenverhältnisse flexibler gemacht, diese waren vorher fest eingestellt. (Man kann in Plasma immmer noch unabhängig von den Seitenverhältnissen verkleinern/vergrössern, indem man die CTRL Taste gedrückt hält.) Das erste Problem ist also gründlich gefixt.

Verbesserte Anwenderfreundlichkeit

Nächster Punkt: Ergonomie. Wie schon erwähnt, schränkt das notwendige extrahieren von CSS2 Selektoren aus Webseiten-Quellcode die Zielgruppe des Widgets gelinde gesagt etwas ein. (Eigentlich sind die recht einfach, was aber nicht heisst, dass ich es auch meinem “Resident non-Geek” zumuten würde — ich hab’s probiert und empfing einen recht leeren Blick als Dank). Ich habe einige Zeit drüber nachgedacht, wie man sowas elegant umsetzen kann. Erstmal wollen wir Quellcode-lesen während des Setup vermeiden, es sollte einfach sein, den gewünschten Ausschnitt auszuwählen, und das Feedback für den Anwender sollte so direkt wie möglich sein. Erster Streich: Die Eingabezeile für das CSS Element hat sich verwandelt in eine editierbare Combobox, über deren Dropdown-Menü man jetzt Elemente auswählen kann. Zweiter Streich: Die URL Eingabezeile hat einen Reload-Knopf zum Nachbarn bekommen, mit dem man eine neue Seite in die Voransicht laden kann (damit werden auch die Elemente in der Combobox erneuert). Dritter Streich: Das Widget zeigt jetzt während der Konfiguration eine Übersicht der ganzen Seite an, und markiert das gerade ausgewählte Element. (Mann kan, wie in allen Comboboxen dann auch mit Maus bzw. Pfeiltasten durch die Liste navigieren, gleichzeitig sieht man im Widget welcher Ausschnitt sich hinter dem kryptischen Namen des Elements (#myid, zum Beispiel) verbirgt. Sobald man bestätigt, zeigt das Widget dann den Ausschnitt passend gezoomt an.

Alles in allem nicht ganz so triviale Änderungen. Da das Widget allerdings bisher kaum benutzbar war, die Änderungen sich recht einfach ohne Änderungen an den Übersetzungen vornehmen liessen, und das Risiko auf Regressions in anderen Teilen sehr gering war, habe ich die Änderungen auch in den 4.6 Zweig eingepflegt. Damit werden sie mit 4.6.1 nächten Monat, und mit openSUSE im März mitgeliefert, und wir somit vielleicht dem ein oder anderen Anwender eine Freude bereiten können.

Hier und da gibt’s natürlich noch Verbesserungsmöglichkeiten. So kann ein erklärender Tooltip hier und da sicherlich nicht schaden, flexiblere Grössenoptionen, wie Proportion, Originalgrösse der Seite (interessant für “flüssige Layouts”), zum Beispiel. Ich habe dafür erstmal sinnvolle Voreinstellungen gewählt, abhängig vom Feedback auf’s jetzige Featureset sehen wir dann mal weiter.

4 Minuten Hobbychirurgie

Abschliessend noch unsere Mitmach-Runde im Mitmach-Web 2.0! Wir haben einen netten Mechanismus, mit dem man kinderleicht eigene Web-Scheibchen-Widgets erstellen kann. Dazu kopiert ihr einfach eine bereits existierende Web-Scheibchen .desktop Datei. Dateinamen ändern (wir wollen ja nichts anderes überschreiben), Namen, Kommentar, ev. auch Übersetzungen updaten (oder einfach löschen, falls nicht nötig), Autor, etc, Einträge die man nicht versteht, einfach drin lassen, auf jeden Fall aber die Plasma Library und Mimetype Einträge. Fügt dann eine Zeile wie diese hinzu, um das Web-Scheibchen auf das Element mit id=”myid” im Tag von der Frontpage von mysite.org läd:

 X-Plasma-Args=http://mysite.org,#myid

Diese Datei muss man dann nur noch nach ~/.kde(4)/share/kde4/services/, kbuildsycoca4 ausführen, um die Plugins und Metadaten auf den neusten Stand zu bringen, und das Widget über den Widget Explorer zur Plasma Arbeitsfläche oder dem Netbook hinzufügen.

Eine mögliche Entwicklungsrichtung für die Zukunft wäre dann, diese selbsterstellten Web-Scheibchen über opendesktop.org mit anderen zu teilen, quasi “Social Desktop für Web-Metzger“…

The Webslice applet has been written by Richard Moore and me as a functional prototype, but didn’t see much love since it was added to Plasma for 4.4 in 2009. Its basic mechanism is that you specify a “slice” within a website, which is a rectangular region. This region then gets shown in the applet, and resizes dynamically with it, zooming the “slice” in and out. The widget basically worked, but had two significant problems: Resizing was very sluggish and bound to a kept aspect ratio, and you needed to know CSS2 selector syntax to actually use it.

Earlier tonight, I’ve committed a set of changes which address these problems, and backported them after review on the plasma-devel mailing list to the 4.6 branch, so these changes become part of Plasma 4.6.1, which will be the first service and translation update to 4.6.0, which we released yesterday.

Performance

First, the resize issue. The Webslice applet uses a webkit view, which displays the page and is positioned (basically scrolled with scrollbars switched off) and zoomed to fit into the area the applet covers — fairly simple in fact. The performance problem was caused by too much resizing which got passed down the stack (if you scroll and zoom a website every couple of milliseconds, it becomes quite heavy on the CPU easily. I’ve addressed this by cleaning up the codepathes that lead to resizing, so that it only causes the resize (and thus the repositioning and zoom of the webpage) when absolutely necessary. Resize events from the applet are now compressed a bit, so that we don’t get more than 10 resizes a second. That’s “good enough” for the user to see what effect his mouse-dragging has, but doesn’t have the sluggish effect. Then, while resizing, I’m freezing webkit’s tiled backing store, for an additional performance boost. The result is very noticeable, the lag and CPU-hogging while resizing is gone, and the sizing of the applet is much less unwieldy with these changes. In that process, I’ve also switched to a non-fixed aspect ratio. Bug #1 thoroughly fixed.

Improving Interaction

Next-up, slice selection. As I already mentioned, that was neither easy, nor user-friendly. (If you’re running, 4.4+, give it a shot, it really sucks ;-).) First off, you need to know CSS2 selectors (they’re quite easy, in most cases you want #myid for an element in the page being marked with id=”myid”), but still limit the utility of the widget to a rather select group. (Does this make the widget 1337?)I’ve been pondering how to best offer this to the user. It should be easy to pick a slice from all the elements that are there. The first thing I did was to turn the lineedit where you’d input the CSS selector (#myid or whatever) into an editable combobox, already containing elements to choose from. That made picking a slice much more “determistic”. Still, the #myid names are not always telling you what part of the page their actually displaying, so some more feedback is desirable. My approach there is the following: When the user opens the configuration dialog, the page is zoomed out and fully shown in the webslice applet, it switches to a preview mode. The user can now enter a different URL, and temporary load this in the slice applet. The combo box containing the elements is now updated to contain the elements of the new page. Website picked, now let’s pick a slice. By selecting a slice from the combobox, the preview mode highlights the position of the currently selected slice in the widget. You apply and it zooms in there. A nice touch is that you can “scroll” through the slice by hovering over the combobox, or flip through them using the arrow keys while focusing the combobox.
All in all, not quite unintrusive changes, but considering the widget wasn’t of much use due to above described problems anyway (there was one bug filed against it — likely a bad sign, I’m not that good a hacker). Marco and Aaron were kind enough to review the patches and agreed that they won’t hurt much, but do provide a nice set of improvements we’d like our users to get fairly quickly, not just next summer with 4.7.

There are a couple of loose ends left for 4.7, though. As I wanted to keep the possibility of a backport open, I’ve not changed any strings in the widget, adding an explaining tooltip here or there might be useful, but also some more flexible sizing options (what proportions to use for the initial rendering — that matters for fluid layouts, how to clip if the size of the widget doesn’t match the aspect ratio of the slice, etc. I’ve chosen “sane defaults” for these things now, but it’ll probably be nice having that available as an option to the user.

Create your own webslice Plasma widgets in 4 minutes

There’s one neat thing left to tell about the webslice: You can easily create your own preconfigured slices. In order to do that, copy and rename the .desktop file, change name, comment, icon, if you wish, then add a line like

 X-Plasma-Args=http://mysite.org,#myid 

Copy the file to ~/.kde(4)/share/kde4/services/, run kbuildsycoca4 and add your newly created webslice to your Plasma using the widget explorer.

A possible direction we can take this is to add a webslice category to opendesktop.org, and start sharing our webslices with each other…

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.

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.

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.

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.

Current Status

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).

Migration

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.

PUSH IMAP

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.

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…

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.

Concluding

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.

This year’s Akademy is significant to me for a number of reasons:

• I’m running for a second term on the Board of Directors of the KDE e.V., the foundation backing KDE. I’ve taken this opportunity to re-focus on my activities there. I will be working towards improving the organisation’s transparency a bit more. Transparency of the of our activities sometimes falls behind a little, since we’re very much focused on getting things done, and there’s always something important to push a little further, at the same time, status information gets outdated rather quickly. With the launch of our Supporting Membership Programme, it’s even more important to get the word out what the KDE e.V. is doing, so that’ll be what I’m working on on that front.
• Last year, Richard Moore and I started Project Silk, which has been silently tagging along. Silently doesn’t mean that we didn’t make progress, just that we didn’t talk about it as much as we could. We felt that we wanted to show results before talking a lot about it, so we sat down and wrote code, worked out concepts, talked to people in order to verify and improve on our ideas. I think we’re at a point now where we got some really compelling stuff to show, and to prove that what we have in mind is not only very viable, but also very important to move on. This year’s Akademy will in part be used to spread those ideas within the KDE team, and to get more people to think Silky. If you think that’s all too vague, attend my talk during Akademy. For the few of you, my dear readers who won’t make it, I’ll prepare some online resources over the next days, so you can catch up as well, and join the Silk bandwagon.
• Meeting my fellow hackers from the KDE Plasma team. After our last meeting in February in Nuremberg, we’re getting together at Akademy next week to plan, hack, gather ideas talk and have fun. What I really enjoy about getting us together is the sparkling you can see above the table we’re working on after only shortly being together. I guess it’s the motivation, the friendliness, the shared love for beautiful, intuitive Free software but also the mutual respect that creates this atmosphere where we’re getting into hyper-creative mode. It puts us in the position to think about solutions for the really hard problems out there, which none of us could solve individually, and it has more than once been the start of exciting new features and sub-projects.

[break] So I just got home, into our hot top-floor appartment in Nijmegen, The Netherlands. Everything’s been taken care of by our terrific friends, the cat is better now after a bladder infection we had to leave it at home with last week. While I do like summery weather, temperatures beyond 30 degrees centigrade without a really cold room are a bit too much for me, and tend to have a bad effect on my productivity. Band-aid: Work at night as much as possible, keep the sleeping room as cool for as long as it lasts and stay in bed as long as I can to get the needed sleep. The laptop is already compiling an updated trunk, while I’m enjoying Brazil playing Chile (Robinho scores the 3:0 as we speak, so I guess my special friend Artur will be happy).

With this new job, I’m also able to spend a bit more time on KDE e.V. things. I’m a Board Member for some time already. Being able to sneak in a bit more of that structured desk time for things that need doing in the near future is surely a good thing. Regarding the e.V., I’ll travel with Ade to Berlin on Friday to meet Celeste, Cornelius and Frank there for an extended weekend of board work (and fun).

(You can download an ogg version on blip.tv as well.)

The problem with this mechanism is that it’s not flexible enough for a couple of things I’d like to do, especially not for Akonadi, and also not for applets we want to create based on a specific web service, or anything else that you can safely derive from the URL. I’ve been thinking about a good solution for this for some time, but didn’t have high hopes to actually make it work in time for KDE 4.4, with the feature freeze looming in only a couple of weeks. On Sunday, I had told Steve (he asked for Akonadi/Plasma interaction, see below) that KJots notes (which are stored in Akonadi) should be drag’n'droppable between Kontact and Plasma (and possibly other applications), and that the way to go would be to pass around typed references to akonadi items by URL (basically akonadi: as protocol, the item’s unique id and its type wrapped into a URL). A lame suggestion in fact, since I knew it wouldn’t work. Then I figured if Plasma::Applet could just tell me which applets are suitable for a given URL (a mechanism similar to the mimetype-based finding of applets), we’d be peachy. Hacked up a patch for that and got it working just before I went to bed, had some good feedback the next day. So I went to clean up and optimise the patch a bit, had it review-boarded overnight and committed it this morning. Applets can now provide matching patterns for URLs. You put a wildcard (or a list of wildcards, useful if you want to cover some subdomains, but not others), in the .desktop file of the applet like this:

[X-Plasma-DropUrlPatterns]=akonadi:*

You can use the usual wildcard syntax, and put in multiple patterns (separate them with a “,”). This makes your applet automatically appear in the popup you get when you drop something onto Plasma. The patch weighed in at 35 new lines of code, quoting Aaron “impressive what’s possible with so little code”.

On an semi-related note, Lion Mail is getting better with every Qt release. Painting and clipping problems I had in scrolling with graphicswidgets seem to be gone completely when using Qt 4.6 snaps. Some automatic relayouting issues remain. Lion Mail’s Email QGraphicsWidget (the canvas-based equivalent to a “normal” QWidget) used dynamic relayouting pretty heavily, as it shows different parts of an email based on the screen space available for the applet. I’ll have to revisit some of this, it might be interesting to take the concepts and implement them using QML & declarative UI tech for that, and also making use of the Pure Awesomeness of steveire’s Elite EntityTreeModel for Akonadi. I’ll let him figure out how this works best for KJots first, though. :)

A couple of notable things happened today in the Marketing of today might also be interesting to share. Jos Poortvliet (of Dot fame) and Frank Karlitschek (fellow board member and social desktop swabian) and Adriaan de Groot (of FSFE and pink whip fame; no whip this time around though, that must be an Akademy thing). We talked a bit about next steps in an effort to put more structure into the various brands KDE has. Right now KDE has many different meanings (a desktop, applications, a community, …). This leads to real practical problems, it is for example hard to explain to everybody that you can run KDE applications also in GNOME, Windows, Mac OS, on Maemo … — it’s called KDE applications because it’s part of the KDE desktop, right? Wrong. That needs fixing though. This probably involves creating a more distinct identity (“brand”) for the desktop / workspace environment and individual applications. This effort is a longer term process, and is well underway already.
Schuberg Philis, the conference’s main sponsor impressed me with a very sensible idea. Instead of having a huge booth with big machines, interesting for geeky folks, the brought in a battery of espresso machines and (so I heard) the dutch champion barista to make coffee. And good coffee it was (I’m still bouncing). Quite a nice marketing performance, not so “in your face”, still a presence suitable for a conference’s main sponsor, in a way that really adds value to a conference — excellent coffee.
The third thing that struck me was the appearance of rekonq’s new icon (rekonq is a webkit-based web browser which integrates well with other KDE applications and the desktop). The rekonq team has taken Konqi (a young dragon) and turned it into an adult dragon. We’ve been playing with this idea in the KDE’s marketing team some time ago, taking our teenage Konqi and make it a full-fledged dragon, sharp teeth and fire included. Cool to see this in rekonq, I think it’s a neat metaphor especially for this app. I’ve just pulled the latest code from its git repo to give it a whirl.
Fourth, Qt marketeer troubalex a.k.a. Alexandra (sometimes referred to as “trouble alex” by certain very funny people), didn’t make it to Ede due to someone in the family being sick, get well soon from the Netherlands.
I also met Koen Vervloesem, who recently did an interview (the link should be publically accessible by now) with me.

One of the talks I attended was held by Bastiaan Jacques. Bastiaan talked about the status of GNASH, and why it’s important to have a Free flash content viewer, even if Flash sucks and is actually not a piece of technology the “Open Web” should move forward with. During his talk, I downloaded the source and tried to build it. There were some issues building it with my Qt 4.6 installed in a non-standard path, which Bastiaan helped fixing after his talk. I’ve added to my “interesting things to investigate” list to further look at gnash and see in how far it’s suitable for displaying content we really cannot get in a better format than flash (and, by design, easy to integrate also in native client applications).

Another talk I attended was the one by Mozilla hacker Paul Rouget. Paul showed some things that are part of the HTML 5 standard, for example the new video and canvas tags, and then quickly went over to show a bunch of demos what you can do with JavaScript, CSS transformations, SVG and the video tags and canvas tags. Pretty fun stuff, although I have concerns if shipping large amounts of JavaScript code that can even do pixel-based transformation and analysis of image is really the way to go for the web of the future. It doesn’t at least solve problems such as accessibility of data for other applications, it is in fact encouraging putting more and more application logic into web pages, mixing content and presentation and making it hard to actually use the resulting content in a meaningful way (think caching, attaching semantic information or making web pages suitable for different input methods and displays). Pretty entertaining, and a good final presentation anyway (let’s be honest, after a long day of technical talks you’re entitled to some bling).

After the conference, I was invited to the speakers’ dinner, held in a nice restaurant in Ede. Food and conversations were good, and it was nice to learn a bit about others view of various topics. All in all a very interesting, enjoyable and generally worthwhile conference.

Work on Silk is also progressing nicely. I’m getting more and more the hang of Webkit and what cool stuff you can do with it. Richard Moore has just been blogging about our adventures with webkit on QGraphicsView. I had collected some information about that during DevDays and the Maemo summit the weekend before where I met Kenneth (at both events), a Danish/Brazilian QtWebkit hacker and Ariya (the food guy) who patiently answered my questions. More about progress in Silk will be revealed in the coming weeks as we’re making good progress.