KMail - making it more usable

KMail is one of the most important applications inside KDE, I think hardly can argue anybody about it. Everybody is using email, and even if some think that a webmail solution can be just as good, most of us still do what we did 10-15 years ago: download mail to our computer/phone/tablet and carry that around.
And for that we need a mail application.
It is not news that KMail got just too big and not flexible enough in the KDE 3.x days. Somehow it was ported to KDE 4, but this was a crude port, without much improvements in its design. A new generic PIM backend was growing up meantime, and with some corporate support from KDAB, a new generation of KMail, KOrganizer and other PIM application started to take shape.
From those I can tell about KMail, as I was more involved into it. As we wanted to have a mobile, touchscreen version as well, the work of porting KMail to Akonadi was done together with breaking KMail into smaller pieces, more or less standalone libraries to reuse as much code as possible. Time, manpower and other reasons limited what we could do, so this was a part success. We created and improves some generic usage libraries (KIMAP, KMime), some internal libraries that are nice, some that are not that nice, and in the end we had something that could have been a good foundation for KMail 2 series.
I started to use KMail2 at that time, and in the beginning it was a fustrating experience. I can't count how many times I deleted and created again the accounts, the Akonadi database. But after a while I realized that I don't have to do anymore. KMail2 was still not released to the public, but got better and better. Unfortunately only slowly, as even less people worked on it, and only in their free time. It had bugs, some more annoying, some less annoying, but was usable enough to not force me to go back to KMail1.
Then the PIM community took a deep breath - just like the KDE community did with KDE 4.0 - and finally released KMail2 officially.
Funny or not, around this time I started to have problems with it. A migration of my second computer failed horribly. A cleanup of the Akonadi database and changing from the mixed maildir to maildir format was also painful. I blamed the developers a lot (including myself :) ). Then things started to move on and KMail got a new maintainer, who is very active (hi Laurent!). And we organized a developer sprint to stabilize KMail.
The sprint took place last weekend in KDAB's Berlin office and was sponsored by the company. Everybody who knows the KDAB office, knows about the famous foosball table. Do I have to said that in the weekend we played only once? Yes, people were coding intensively, Volker had to raise the priority of the "FOOD" topic often.
Issues were listed on the whiteboard. And everybody picked up what he was interested to do. Work was done on the migrator, the mixed maildir agent, the maildir resource, on the akonadi server, performance bottlenecks were identified and a new filtering resource was created, fixing the most hated KDE bug (should be closed as soon as Tobias Koenig is happy with his work).
My choice in the sprint was mostly maildir related work, I tried to make it more reliable, more standard compliant and somewhat faster than before. And the biggest win is that I fixed most issues that bothered me with KMail's maildir handling. Yes, I was selfish.
The sprint did not end in Berlin, for me it continued on the flight back home (that thanks to the weather and Lufthansa was almost a day longer than expected). And somewhat still continues as of now, although daily work reduces the time I can allocate to KDE.
I can say that I'm happy again with KMail and Akonadi starts to gets less and less in the way of me and the users. The biggest success will be when users will not know that there is a nice server helping them, called Akonadi.
For those eager to try out the changes, unfortunately most of them are in the master branch only (the upcoming KDE 4.8). We will try to port as much as possible into the KDE 4.7 bugfix releases, but as some changes required library additions, this won't be always possible.


Great news :)
I'm using kmail2 for a few weeks now, and apart from minor annoyances, it works. The key for me was to create a completly new configuration. Any migration I tried was a mess.

Anyway, thank you!

By gaboo at Wed, 09/21/2011 - 22:03

Is there any chance the messy config UI will be cleaned up?
I feel a complete do-over would be needed. And while I have an eye for usability, that case would be such a big task that with my lack of proper training I couldn't do it myself.

By kamikazow at Thu, 09/22/2011 - 10:37

To be honest, this part was not yet taken into the account. Suggestions are welcome, be it mocups, or even better in form of code. :)

By amantia at Thu, 09/22/2011 - 19:50

Thanks for your work on making KMail better. For me it's really app number one and using Zimbra web interface is lot of pain. But in 4.7 it's the only possibility for me - KMail, Akonadi, Virtuoso, Nepomuk and Mysql makes my quad core feeling like 286 with turbo off. With disabled Nepomuk it's much more better. And strange thing is - it works sometimes very well, fast but most of the time it's too slow.

Yes, my account is about 3 GB of mails but it's too late to do cleanup and not to delete important stuff I want to look for later :)

If I can help you with debugging the slowness, feel free to ask any questions. I'll try 4.8 branch too.

By rezza at Thu, 09/22/2011 - 12:27

Helps is always welcome. I also have a fairly large maildir dir, that started with KDE 3 days I believe. :) If you have time, you might try to identify when does KMail behave slowly. If you do that by using profiling tools, like valgrind --tool=callgrind, even better.
There are some things we can't do too much tough, like original importing of the data. That is too IO bound, reading 3GB of mails and extracting the headers from that will take time, no matter what you do.
But there are certainly parts that we could improve. We already identified some issues with the model stack used in KMail and another issue (IMO) is the message listing widget. But of course the more reproducable a case is, the easier to find a solution, so creating good reports how to exactly get a slowness or profiling the slowness you have would be appreciated.

By amantia at Thu, 09/22/2011 - 19:49

What KMail needs for the UI, is to support Ctrl+M functionality to hide menubar in every window (Main window and New email window).

This is how KMail should be possible to configure without Third party themeengines (QtCurve) what does not even work well (New Email window has always menubar visible by default)

Same time it would be great if someone would fix the problem in KDElibs by supporting a configure some of the toolbar buttons to be alligned to right side instead always on left side.
Results would be these:

As you can see, "Add Image" and "Attach file" buttons are on rightside of toolbar and not on left.

So when combining those two features, it would be much better than current situation what looks like this

By fri13 at Sat, 09/24/2011 - 16:59