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.
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.
On the website of an Austrian (no kangaroos!) newspaper, I read an interview with Canonical’s Jono Bacon. In this interview, Jono talks about the process of developing central components of the desktop inside Canonical. The process is basically that Canonical’s design department, Ayatana develops components. When they are finished, they’re offered for inclusion into GNOME, which was not a successful in all cases yet. According to Jono this is "working upstream", explaining that in this context Ayatana is the upstream. GNOME is seen as a provider of components, building blocks for Ubuntu’s user experience.
The definition Jono handles of upstream development is quite different from how it works for me. I can speak of personal and professional experience in this context, as I have been working quite a lot on central components of the Plasma Desktop (and Netbook as well). I have done this work both, as a voluntary contributor in my Free time (pun intended), and continue to do so in my working hours for open-slx. open-slx happens to sell and support Linux deskop operating systems.
Nowadays, many of my contributions to Plasma and KDE in general are paid for by my employer, open-slx. As part of my job, I am allowed and intended to work inside KDE during working hours, this includes "hacking on Plasma stuff" as well as taking on some organizational load, such as working in the release team and the KDE e.V. Board. open-slx’ philosophy behind this is that it is essential to play nicely in the community as a company, and that selling a product which heavily relies on its user experience is made easier, not harder by working directly in the context and infrastructure of the project we intend to merge our creations into. In my case that’s KDE, and especially the Plasma team. This means that I commit my work directly to KDE’s source code repository, that design and technical decisions are being taken in the approriate upstream communities. This can happen for example during sessions at Akademy, at sprints, on IRC and most importantly on mailing lists such as plasma-devel@kde.org and kde-pim@kde.org.
The latter two are a nice example for a project I’m currently working on, the Akonadi-based email notification system. During Akademy, I sat together with a bunch of the KDE PIM developers, to design the new email notification system that will likely come along with Plasma and KDE PIM 4.6.0 next January. Over the past weeks, I’ve spent quite some hours on working out the plans. I’ve committed my changes to the code right away to KDE’s SVN to share them with others. Once the code is "good enough", it’ll be submitted for review and inclusion into Plasma or PIM, whatever makes more sense from a packaging point of view. It will be released together with Plasma 4.6 next year and through openSUSE 11.4 will be part of open-slx’s next product, the boxed version of openSUSE. This way, these contributions, the working hours my employer pays for trickle back into our product via downstream projects such as KDE Plasma and PIM teams, and openSUSE. The initial design of the new Plasma email notifications has actually been born during Camp KDE 2009 on Jamaica, but that’s a different story altogether. If you now are interested how that actually looks like, that will be the topic of another entry on this blog.
Let me get this straight, though. It makes sense to provide modifications to the user interface as add-ons that other companies with a similar product don’t ship. Also products based on Free Software need unique selling points in order to make their whole enterprise commercially interesting and viable, and thus make money flow into the development of Free Software.
On the licensing side, this is expressed in making it possible to write proprietary components, for example by using the LGPL license for libraries — Qt, kdelibs and libplasma are all licensed under the LGPL for exactly that reason. Technically, systems such as Plasma’s widgets which can replace any part of the whole Plasma Shell, be it the display of notifications (which Aurelien has actually proven by writing a Plasmoid that displays notifications according to Ayatana style guides), the taskbar, or all kinds of online services. From a branding point of view, the simplest case is probably slapping your branded wallpaper onto the default install. More advanced usages would be a customized Plasma theme, or maybe even "fingerprint animations", that make using your desktop feel a bit more special. For open-slx, Plasma turns out to be an excellent choice of toolkit to build an improved user experience upon, and that is true: we can virtually turn Plasma into any kind of product we like functionally, we can make it behave and look like exactly as we like, and we can maintain a clear separation between aspects we think are the unique selling point of our product, and the contributions we make directly upstream as part of being a good citizen in the KDE community.
The point here is that in order to sustain a Free Software eco-system such as KDE, or maybe GNOME (like in Canonical’s case) you need a healthy balance in your contributions to the upstream community, and your work to differentiate yourself commercially. It’s good practise to make a clear separation between the things you choose to be your USP and your Free Software contributions. Communicating clearly what your contributions are and where you are "commercially sensitive" is both essential: You want to create goodwill among developers that don’t get a paycheque from you (so-called "community support") when you need their help in a context that’s commercially sensitive to you, and which you want to keep separate for licensing and marketing reasons. Moreover, this clear distinction between your proprietary add-ons and your upstream contributions make it clear to customers why to buy your product, and not the competitor’s one.
I’m on the first leg of my trip back to the Netherlands right now. I’ve spent a couple of days in Bretagne, France to celebrate the marriage of a close friend, who asked me to be his best man. The celebrations, which lasted for three days were terrific, but also pretty tiring as you don’t get to spend much time just by yourself. The main celebration was held in the "ridiculously beautiful" Chateau Domaine de la Bretesche, and in Pornichet, the home of the bride. I’m returning to the Netherlands right now, for three days of desk time (needed to prepare my Akademy talk and to get some last minute work done on the impending openSUSE 11.3 release). On Friday, I’ll be boarding a flight to Helsinki and then on to Tampere to take part in my fifth Akademy.
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).
I’ve resigned my job at KDAB last month in a swift move towards more KDE-time. This all came pretty suddenly, but it felt like The Right Thing to do for me personally and for KDE, which I care a lot about. Since May, I’ve been working for Open-SLX, a German company that makes and supports the openSUSE boxed version. My focus in that work is the user experience of the product. The idea is to work upstream (in openSUSE and KDE / Plasma) as much as possible. While Open-SLX benefits directly from my work done in KDE, this is also a nice way to give back to the community, by making sure I get to spend enough time on things that are not directly related to the product. So now I’ve settled into my new job, and up until now, it’s been great. I’ve been able to catch up with a couple of areas in KDE, I didn’t get to spend as much time as I wanted in the past, and I have started working on some ideas I was dragging around in the back of my brain for a while). One of those things is Project Silk, which is a Project to boost and deeply integrate the web into KDE Plasma and applications. Its motto is no less ambitions than "Freeing the Web From the Browser", so there’s lots of work to do. ;-) Others have already shown off their coolcreations, so I’ve got some catching up to do. I’ll share more detailed information about Silk in the next weeks, so if you’re interested in that, hang on just a little bit longer.
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).
Thanks to my unrestful ex-colleague and current coffee-buddy Ade, my blog is back online, as you can see. Now I have to figure out why Blogilo works fine on one machine, but has problems getting my blog’s metadata on another one (my laptop). Blogilo is another one of those applications from the category Internet I’d rather not live without. Writing blogs offline (on trains, for example), adding media (screenshots for example, those seem to be quite popular) to blogs is just so much easier if you don’t have to deal with the uploading yourself but get it done in the background. And now I’ve mentioned screenshots, I should probably also show one (since it’s that easy). I’ll pick the new interface details in the Network Management plasmoid. In the screenshot, you can see what you get when you click on a network interface, it’ll show you additional information about the interface, and if connected some basic traffic stats. For this, I’ve used the systemmonitor dataengine and the Plasma::SignalPlotter widget, so the patch to add this nice little feature weighed in at only about 50 lines of code. The widget only updates when the details are shown to save power cycles when it’s not in use, but you can switch to the details and then dismiss the popup (which happens automatically with our focus policy), and it will keep collecting data. If you switch back to the normal view (using the back button), it’ll stop updating. I’m also happy to have received Andreas Demmer’s first patch today, which looked good right away and has been merged already. He changed the back button in the details widget to be more consistent with other buttons, so that’s a nice addition. Andreas has been keeping an eye on the development of the networkmanagement plasmoid, and has been providing useful feedback in the process. So there’s another step on the ladder towards hacker-heaven. (Yes, Plasma development is *that* cool. :-))
Another thing that plays a rather important role in my daily workflow is the Quassel IRC Client, which is an IRC client that allows you to easily use different machines for your IRC needs, without the need of logging in and out all the time and losing the history of your conversations. So if you found my IRC presence to be wonky during the last days, it should be better now.
I hear you asking "The real relevance of this post is…?" Well, api.kde.org is also back online, so your Konqueror shortcut "kde:<classname>" works again — although I’d expect that by now, every sensible hacker has loaded this file into Qt Assistant (Edit | Preferences | Documentation | Add…) and have both Qt and KDE docs available in one place.
Today, a package was delivered to my house containing an item which I’ve been missing for a long time, years in fact. A second battery for my laptop. I’ve been working on various power management solutions in KDE in the past years, and they all had one problem: I couldn’t really test if everything worked with more than one battery plugged in. In that area, I always depended on others to help me debugging and fixing problems, not the ideal workflow, so some bugs have gone uncaught in the past.
Not anymore! Now I’ve got this second battery in the optical drive slot of my dear Thinkpad T60, I can immediately identify problems with displaying the charge rate of more than one battery, and I did. One bug displaying a wrongly formatted translation string in the battery’s popup has already bitten the dust, within one hour of delivery of the second battery, I committed a patch to the 4.4 branch and trunk of KDE SC. As far as I can see, showing the charge rate of multiple batteries basically works. I’ll probably find more room for improvement as I use this new setup, but for now, rejoice!
It’s out. Yes, finally. This release has been a bit of a bumpy ride. First thing was that we decided to do the release two days later, because on Tuesday (the date we’d initially planned), we already had KDE 4.3.4 scheduled. Then, yesterday, Dirk, our package-it hero had to struggle with some build problems in various modules.
Still, this is not a perfect beta. When trying 4.4 Beta1, you might find yourself without compositing effects. This problem has crept up in the last two weeks, and we’ve been only able to fix it this morning, too late for the beta. It turned out to be a problem of stricter capability checking, along with a change of the driver version string reported by mesa. Dirk said, he’ll roll another set of source tarballs next week, so you’ll get your compositing effects back. In the meantime, please focus your testing on other problems.
Allen was concerned about a bug that prevents KOrganizer from starting. We though about disabling KDE PIM for this beta, but in the end left it all in since we do want applications tested, buggy or not.
As you see, we’ve clearly shifted focus from get-your-features-in-mode to bugfix-mode. I’ve had a quick look at the statistics. In the past six months, we’ve closed about 18000 bugs in KDE’s bugzilla. Since the release of KDE 4.3.0, we’ve been able to close about 12400 issue reports. Over the last 7 days, we’ve closed about 900 bugreports. I think we should aim at 20000 closed bugreports until the release of 4.4.0 in February.
A “closed” bug means that a bug is either fixed, a duplicate of another bug that has been fixed, or that the bug cannot be fixed in KDE itself. This is the case for upstream (and sometimes also downstream) problems that really need a fix elsewhere. Some bugreports will also be marked “invalid” or “wontfix”, in which case the bug is actually not a bug (that happens :)). In any case, it means that we’ve triaged the bug and looked into it. Bugzilla is one of the important ways to feed back information to the KDE developers.
Of course you can help with the bug-hunting. Collecting data from a large variety of people, systems and usage scenarios is important to find corner-cases developers weren’t able to test or just didn’t think of. Please report those issues you run into! When doing so, for developers it saves a lot of work if you have a good look if your bug is already reported, don’t assume it is, but also don’t assume it isn’t.
When you’ve reported a bug, it’s helpful when you’re responsive to emails and check on your bugreport once in a while. We might need further information, there are often workarounds, and in some cases, it’s helpful for fixing a bug if we have short feedback cycles with someone who’s actually experiencing an issue to check further, or maybe ask to run a patch. The better your bugreport is, the easier it is for us to fix it.
Of course, KDE being Free Software, you can have a go at fixing some problem yourself, the source code is readily available, and if you know a bit about programming, issues are often easy to find and fix. In general, I find the KDE source code to be easily readable and understandable. In doubt, you can always ask another developer for directions, on IRC or one of the -devel mailinglist.
So, what’s so significant about KDE Software Compilation 4.4? Well, it’s a huge package of software, dozens of applications, a kick-ass development platform and an organic and usable desktop shell. One of the more noticeable changes that really cover all applications are probably the subtle transition effects that have been added to the Oxygen widget style and window decorations.
Another doublepluscool feature is the tabbed window manager. This new feature makes it possible to group arbitrary windows using tabs. You can now simply drag a window with the mouse wheel pressed onto another window and they’ll be grouped in tabs. The tabs are part of the window decoration, detaching windows works in the same way. Another very nice feature is the edge snapping. Dragging a window against the left or right border will put it on one the of side of the screen, exactly at half of the width. Dragging against the top edge will maximize a window. This way, you can easily tile (and group, with window tabbing) arbitrary windows.
I’ve stumbled across a nice video of some of the visual changes in KDE Plasma 4.4, you can find it here:
There have been quite some comments to my previous blog, among them some good points how to further improve the clarity of the battery applet’s info and control panel. I thought the best way to address this is with a patch, and a bit of explanation of those changes. So here’s the dialogue after a bit of further hacking on it:
Let’s look at the latest changes:
Bigger informational text, bold labels — Checking the charging state is the primary usecase of the panel, adding a bit of visual weight to the top section makes it easier to spot the information
Separator between info section and controls removed — As some people pointed out, the separator between the info and the control section resembles the brightness slider a bit too closely, and distracts visually
Configure button moved in line with the profile combobox — This is actually a very good point. It makes sense to put the configure button next to the profile combobox. The button actually leads to the profile configuration settings. It also makes it possible to …
Move Sleep and Hibernate buttons in line — Now we have two instead of three buttons in the lower section of the controls, we can actually put them in line and get rid of the large hole in the lower part of the dialog.
Aligned labels and controls horizontally — This last one is a label alignment bug in my code notmart quickly fixed after seeing the screenshot. Thanks dude! :)
I think that it works indeed better visually with those changes. The separation between info section and controls are better, the alignment of the widget overall is clearer, and as you can see, we’ve also saved quite some horizontal space. While it’s certainly not perfect yet, I think it’s a really nice improvement. Thanks to those who came up with the suggestions. I’ve just committed the patches to trunk, so they’ll be in KDE SC 4.4 beta next week.
On a sidenote, I had to order a new battery today for my beloved Thinkpad T60. The battery I’m using is, as you can see totally worn out. If you, dear lazyweb have suggestions how I can revive my (by now three) worn out accus, I’d be most grateful. I guess the constant plugging and unplugging of the accu and power cable isn’t the healthiest diet for this kind of hardware. Ow sacrifices … ;-)
Update: I’ve removed the percentage from the battery picture in the dialog, since it’s redundant (already displayed next to the “Battery:” label). Also, the dialog now reacts to font size changes on the fly.
The battery applet in KDE Plasma 4.4 has gotten some nice improvements. First of all, I wasn’t really happy with the layout of its popup dialog. It looked messy and didn’t scale well with bigger fonts. During Tokamak3 in September, I started improving this. To make it look calmer, I reduced the amount of edges widgets are aligned to. The previous version used nested layouts, which lead to widgets not properly aligned with each other. This creates a rather messy look. For 4.4, I’ve reworked the layout and reduced everything to only one layout and attached the battery in the popup off-layout in the top-right corner. I thought about using an AnchorLayout for this, but a simple setGeometry() to position the battery top-right would work as well, so I went for KISS. I also replaced the text on the "Configure Power Management" button with a tooltip, reducing visual clutter but keeping this handy in-context shortcut to easily get at the more advanced power managment settings.
The battery popup now resembles a FormLayout more closely, which should make it more consistent with how other dialogs in KDE are designed, so that’s a bonus in consistency. The two screenshots show the old and the new version of the applet side-by-side.
One wish came up more than once over the past months. Some (very vocal) users would like to see the battery showing the remaining time when it’s running on battery. Normally, the applet would show the charge percentage, which is a rather abstract number. (How long is 37%?) Now unfortunately, there’s no way to give an accurate estimation oft the time that’s left, since it largely depends on the usage patterns. You check the battery, it says "10 minutes left", then you start some app that exercises your CPU and disk and suddenly the machine goes into suspend after 3 minutes. Quite possible, and the usage scenarios and differences in modern portable hardware are such that there’s really no way to accurately predict the remaining battery lifetime. In the Plasma team, we decided that we rather not show the user unreliable information, since there’s only a very small group that understands that this number is almost black magic, and often simply wrongly reported by HAL. There’s well over 200 emails on that subject, mainly on the Plasma mailinglist and everytime this topic comes up we hear how much KDE must suck if this tiny little feature isn’t available. We’ve made this feature available in KDE 4.3, as a hidden config option (meaning that you cannot enable it using the configuration UI, but it’s there if you enable it in the configuration file. I had tentatively disabled this code during the larger part of the 4.4 development cycle to see if I’d get away with ditching it, and it didn’t quite fit in with the new layouting for the popup. Lately, the same discussion came up again, hopefully for the last time, since I submitted a patch yesterday night that brings the remaining time back (still as hidden config option, and that’s about as far as we will go). No, there won’t be a checkbox since I don’t want to confront users with information that’s most likely bogus and highly depends on what you’re doing at this very moment. As the option needs a power user to understand what this info really means (i.e. an estimation that’s completely off or not, depending on what your BIOS or ACPI subsystem reports), I think we can reasonable expect that adding a line to a config file is easy enough for those who really, really, really want it.
So, for reference, here’s how you get the remaining time display in the battery applet.
Install KDE Plasma 4.4, at least trunk from today
kquitapp plasma-desktop (to stop your plasma shell, as long as it’s running, it can’t pick up config changes, if you stop it after you changed the config file, it will happily overwrite your hand-made changes on quit)
Open your plasma-desktop config file, (mine is ~/.kde4/share/config/plasma-desktop-appletsrc, YMMV)
Locate the section for the battery applet, in the below example, you’ll find the plugin=battery line, choose the section that adds [Configuration] to the identifier. This section might not exist if you’re using default settings, in that case, it’s easiest to check the “show charge information” checkbox in the battery’s config (you might need to restart plasma-desktop for that, don’t kill it afterwards but use kquitapp). Then locate the showBatteryString= line and add another line in the same section:
showRemainingTime=true
Save the edited config file, restart plasma-desktop
The remaining time will now be shown if it’s non-zero (obviously bogus since the machine would be off then) and the battery is discharging. If in doubt, use “plasmaengineexplorer –engine powermanagement” to check wether Solid reports the remaining time at all, and that it’s non-zero. The remaining time could also be shown while charging, but this apparently isn’t supported by my setup, so I can’t test it.
Also during Tokamak3, Dario fixed a bug that would switch the display’s brightness back to 100% after it was dimmed because the machine had been idle. So if you’d set it to 50%, and it would then dim after some minutes of idle time, you’d move the mouse and it pops back to 100%, while it should go back to 50%. That’s fixed as well, and the patch has also been backported to KDE 4.3. You probably are already running with this fix.
Update: I’ve just committed a couple of changes to the battery applet and explained them in a follow-up blog
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.
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.
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.
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.
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.
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.
Thanks to my unrestful ex-colleague and current coffee-buddy 
Today, a package was delivered to my house containing an item which I’ve been missing for a long time, years in fact. A second battery for my laptop. I’ve been working on various power management solutions in KDE in the past years, and they all had one problem: I couldn’t really test if everything worked with more than one battery plugged in. In that area, I always depended on others to help me debugging and fixing problems, not the ideal workflow, so some bugs have gone uncaught in the past.
Let’s look at the latest changes:
One wish came up more than once over the past months. Some (very vocal) users would like to see the battery showing the remaining time when it’s running on battery. Normally, the applet would show the charge percentage, which is a rather abstract number. (How long is 37%?) Now unfortunately, there’s no way to give an accurate estimation oft the time that’s left, since it largely depends on the usage patterns. You check the battery, it says "10 minutes left", then you start some app that exercises your CPU and disk and suddenly the machine goes into suspend after 3 minutes. Quite possible, and the usage scenarios and differences in modern portable hardware are such that there’s really no way to accurately predict the remaining battery lifetime. In the Plasma team, we decided that we rather not show the user unreliable information, since there’s only a very small group that understands that this number is almost black magic, and often simply wrongly reported by HAL. There’s well over 200 emails on that subject, mainly on the Plasma mailinglist and everytime this topic comes up we hear how much KDE must suck if this tiny little feature isn’t available. We’ve made this feature available in KDE 4.3, as a hidden config option (meaning that you cannot enable it using the configuration UI, but it’s there if you enable it in the configuration file. I had tentatively disabled this code during the larger part of the 4.4 development cycle to see if I’d get away with ditching it, and it didn’t quite fit in with the new layouting for the popup.