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.

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.

So it’s finally out. After a 6-months long release cycle, and 6 months and one day after the release of 4.4.0, KDE today presents 4.5.0. The focus of this release lay on polish, performance and bugfixing, so I can happily recommend 4.5.0 to everyone using an earlier version, or someting entirely different. Have fun using 4.5 :)

Last year, something pretty awesome happened. One of the world’s most widely used operating systems got released under a Free license. Nokia and her partners worked very hard, and were even able to get through the legal jungle that’s always involved in such high-profile projects very quickly. The result was that the source code for Symbian became available much quicker than initially thought it would. How’s that for a project finishing early, instead of late?

Some months ago I was contacted by the Symbian foundation, who were in the process of setting up the Symbian DevCo, a non-profit organisation registered in the US which will relay between the Symbian foundation and individual developers who wish to take part in developing and directing the future of the Symbian operating system. Coming from the mobile phone industry, which hasn’t been known to be very open in the past, the governance model of the Symbian ecosystem is very much aligned to what works for large corporations. That means that if you want to take part in decision-making, or in maintaining packages in the official Symbian upstream, you have to be a company. Now most players in this ecosystem are, but requiring to be a company can also pose potential barriers to those many who can bring a lot to the Symbian ecosystem. Being able to toy around and develop using a certain technology without any restrictions is at the heart of any open eco-system, and this is where the Symbian Developers Cooperative (or simply devco) comes in. The Symbian DevCo gives a voice to individuals involved in Symbian.

Taking part as an associate in the Symbian Developer Cooperative means that individuals now have

• The ability to become a Symbian package owner
• The ability to be nominated for a seat on the Symbian technology Councils
• The ability to be nominated for a seat on the Symbian Board of Directors.

Those are three important privileges which have previously not been available for individual developers, and I think they’re absolutely critical to opening up the ecosystem, in tandem with Symbian’s source code. In order to low the barrier for participation even more, becoming an associate is free of charge.

My Role – President

That’s what it’s called officially. I’d personally much rather think of it as sanity checker and get-things-go’er. During our first board meeting, which happened last Tuesday, we talked a bit about the roles within the board. My prerogative was, from the beginning "Do not come back with a treasurer’s hat", as that would not be good for anybody involved. (I’m good at spending money, not good at keeping tabs, and even worse at that pesky thing called "acting responsibly". ;-) My idea of this role is to learn, to listen and to get people involved that really care about an independent governing process of the Symbian platform.

While I have to admit I’m rather green when it comes to Symbian, and its ecosystem, there are measures that should alleviate this. First of all, I’m an eager learner, and secondly, much more important, there’s the advisory board which does exactly this: Advise the board, bringing in expertise from the industry and the Symbian community. And if someone comes along who fits the shoe better, I’m all for passing it on. For now though, it’s important to get the thing running, and my experience in running the KDE e.V. together with my awesome fellow board members there comes as an advantage.

This position is voluntary, meaning I do it deliberately, and that I don’t get paid to do it. Well, technically, my awesome boss allows me to spend some of my work-time on this, but it’s all up to me how much that will be. After all I have this time-consuming hobby called KDE already (which also is part of my job). (This is just so I can say that I’m spending 60 hours or more a week on work-work, while in fact large part of work-work is fun-fun. Confusing, but awesome if you ask me.

Isn’t Symbian on the Demise?

It surely seems so. On the other hand, that doesn’t happen within a day or two, and according to analysts, we’re looking at at least another 5 years of Symbian being very relevant in the mobile space. A lot can happen in 5 years, so I think my time is definitely spent well. As of today, Symbian sales are still staggering: 260.000 Symbian-powered devices are sold each day, that’s slightly more than 3 per second (figures are based on the 1st quarter of 2010).

In the end, what matters to me is Software Freedom. Which technical implementation is leading us there is only secondary. If Software Freedom comes a bit closer today, and I think that’s what happened with the release of the Symbian operating system and the opening up of the ecosystem, I’m a happy person and glad to play my part. Taking this responsibility to lead in an area that’s traditionally (and understandable) a weak aspect of the Symbian (and in extension) mobile ecosystem is how I contribute to a world where Free Software is the norm, rather than the exception.

What about KDE?

Does this mean I will leave KDE? Surely not, my role in the Symbian DevCo is only part-time and voluntary. I’m as much motivated and committed to moving KDE forward as I have ever before. My involvement with Symbian will mainly have positive effects on my participation in KDE: my expertise and angle of view will expand, and like the Symbian DevCo benefits from my expertise in running a community-driven Free Software organisation, KDE and the KDE e.V. will benefit from the new insights and expertise I’m collecting as part of my involvement with the Symbian DevCo. Simply Symbiantik, isn’t it? (Ok, I just had to finish this boring blog entry with something really cheesy. Mmmhhhhmmm cheese…)

To make this blog entry slightly more useful, I’ve found the Android WordPress application pretty handy. In order to prevent spam, I’ve enabled moderation for the first comment of a person. This way I can more easily keep moderation times down and make that necessity a bit less annoying by quickly approving non-spam comments on my blog. The Akismet spam filter is already pretty good with 99.8% accuracy, the overall ratio spam vs. comments being roughly 50/50. Comment spam that slips through Akismet is caught in moderation, that way I can make sure that no spam shows up at all. WordPress on Android makes the approval process rather handy. It would be nice if the app could automatically check for comments and notify of new ones that need moderation though. If you don’t like web browsers to manage your wordpress blog, I find Blogilo as a desktop client and wordpress on Android app a very nice combo.

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

As users’ needs vary, we decided to make the Akonadi port of KMail opt-in for the 11.3 cycle. openSUSE 11.3 is based on KDE SC 4.4, and as such will install the "mostly traditional" PIM suite. Users will not automatically be upgraded to KDE SC 4.5 (which is due in August), but in all likelihood it will be easily installable. As there are many people who follow KDE releases closely, many will install SC 4.5.0 and followups from the Factory repositories, so when 4.5.1 is released, these users’ email would get migrated to Akonadi automatically. That might come as a surprise, as it’s unconventional to make such a big technological leap in what looks like a bugfix update. So in openSUSE, we will keep shipping 4.5.0′s KDE PIM even in Factory, but also make available packages that replace KMail1 with KMail2. Users will be able to opt-in to the Akonadi migration, so they can do this upgrade when it fits for them. From a discussion with the PIMsters, it also looks a lot like you can try the Akonadi-based KMail, and if it’s not ready for you yet, you can switch back to KMail1 without losing your config. That’s a great achievement by the PIM team, and shows that they’re developing with end-users in mind.

For the user, this means that for the innocent nothing will change automatically in the upcoming cycle (other than bugs getting fixed). The effect is that there will be a roughly 6 months long window in which users have the choice whether they just want their KMail to not change, or to jump on the Akonadi bandwagon into the future.

This upgrade also gives us (upstream KDE and downstream openSUSE) the opportunity to make the migration and workings even smoother, and deliver some icing on the Akonadi-cake with the openSUSE 12.0, which show why Akonadi is a darn useful thing to have. I know many people (and I am one of them) who are looking forward to make full use of Akonadi, not only in the applications you’d expect it to be, but also integrate all the interesting information from Akonadi also in other apps. I’m sure some very interesting features will crop up after Akonadi is fully upon us.

I’m now running openSUSE on my desktop, which has an AMD RadeonHD 4350 card. That card is fast enough for my graphics needs (compositing window management, a dated game once in a while) and still passively cooled and providing two DVI outputs for my dualhead setup. I’ve been using an NVidia VGA before, but switched to AMD/ATi when I last upgraded my desktop workstation (to an Intel Quad core, meaning new mobo, graphics as well). I picked a RadeonHD card instead of an NVidia chip because of AMD’s open dealing with specs, something which I deeply despise in NVidia. So, NVidia, there you go: You lost me as customer because you’re too closed a company.

Now bitching about NVidia is not the (primary ;)) goal of this post. The goal of this post is, that with openSUSE 11.3′s graphics stack, I’ve been able to run a composited desktop with the Free radeon driver finally. While there were some hickups in the installation procedure (normal for a beta release), it now all fell into place, and I’m enjoying fast, beautiful graphics with a completely Free software stack. That is a lot of work from the Xorg people that has finally come to fruition: There’s the new DRI framework in the Linux kernel, along with drivers supporting compositing for many of the "newer" RadeonHD models, the compositing support for newer chips that has landed in the latest Xorg, all on top of the EXA acceleration infrastructure. If you’re interested what you can expect from your upgrade to 11.3, check the feature matrix compiled by the Xorg devs.

I’ve tried the setup on Ubuntu Lucid Lynx in the first place, since that’s what was installed on the workstation before, but didn’t have much luck. The kernel shipped with Lucid is just one version too old it seems, so lacks the functionality necessary to accelerate graphics suitable for compositing. For that reason, I’ve upgraded the kernel to 2.6.34, but only to find out that my Xorg is not good enough. Tried installing newer packages from the xorg-edgers repo, but that just resulted in my system hanging solidly during boot. (That’s to be expected if you’re using bleeding edge Xorg, and upgrade your own kernel, but still a shame it didn’t just work ;-)). I assume that new upcoming Ubuntu will provide this nice out of the box experience as well, but I didn’t try it.

For many users, the most interesting thing is probably that the Free radeon driver (and to some degree the Intel graphics driver as well) provide the best user experience for running a KDE Plasma desktop. Using the NVidia driver, the desktop always feels sluggish. That’s supposedly due to NVidia not accelerating some calls that are made while switching windows, so a couple of milliseconds are added there and the whole thing feels less responsive. It’s not as bad as it was, about 2 years ago, but there’s still a notable difference in snappiness when using a low-end (non-poulsbo ;)) Intel chip compared to anything using the nvidia.ko binary driver — and that’s just pathetic given the NVidia hardware is supposedly much more powerful. The same, even if to a lesser degree, is true for ATi’s binary driver, the (in)famous fglrx.ko. This one, while it works OK-ish, also suffers slightly from this lagginess. Switching to the free driver makes the whole thing just very snappy. I could well imagine that those who are complaining about a perceived slow system are suffering from just this problem — bad graphics drivers. If you’ve recently compared the binary and free drivers for RadeonHD cards, please leave a comment so we can see if this — rather vague — theory of mine (binary drivers suck, Free ones feel faster) is true for more people.

So, what’s the epic moment? Well, the epic moment for me was seeing KDE Plasma start up with the Free driver, enable compositing automatically and by that delivering a much more beautiful and functional desktop to me, out of the box. I’m happy that with the new graphics stack in openSUSE 11.3, the same will be the case for many users out there.