This is an ancient post, published more than 4 years ago.
As such, it might not anymore reflect the views of the author or the state of the world. It is provided as historical record.
WARNING: This is a rant. You have been
warned.
This bragpost has been growing on me for some time now. About since
the very day I had the questionable pleasure of trying out Akonadi-based KMail2. That would be about
2 years, and back then KMail2 was buggy and slow.
Today it is buggy and on the verge of being almost possible to
consider as trying to be usable. That’s how far this project has gone in
these 2 years.
Good Ole Days
In the Good Ole Days, and by that I mean “pre-KMail2”, there were
more or less two kinds of FLOSS e-mail clients out there.
Bad UI, decent engine – Thunderbird was an
example here; compared to KMail 1.x, Thunderbird had completely absurd
layout of configuration options and doing simple things (like creating a
new e-mail identity and connecting it to SMTP and IMAP/POP accounts)
seemed daunting.
Completely subjectively I include in this group also Evolution and Mutt,
simply because I use KDE (hence GTK is bad mojo) and am a GUI
afficionado (yeah, yeah, so shoot me).
Great UI, great engine – in my book, this group
consisted of just one project: KMail 1.x. It had everything:
IMAP/POP/SMTP, TLS/SSL/STARTTLS, Sieve, advanced local filters, multiple
identities connectable not only to specific accounts but to specific
mail folders, proper standards support, proper quoting, and everything
configurable via a sane interface with predictable results. All mail
kept nicely in standard Maildirs so that KMail’s mail was the easiest to
handle by any standard Maildir tool.
And from verions to version there actually were incremental
improvements still. What’s not to love!
What the hell happened?
Since then the KMail2 team apparently decided to take a different
route, which I would guess was something along the lines of:
- take the best e-mail client out there;
- mangle in ways nobody would believe were possible;
- ???
- PROFIT!!
And thus today KMail2 lands squarely in the “WTF UI, WTF engine”
category (at least retaining the “the only one in that category”
title).
So, what’s wrong with
KMail2, exactly?
Well, what isn’t?.. Not really even sure where to start. So let’s
start with the “migration assistant”.
Migration assistant
The first time a user runs KMail2 over an existing KMail 1.x setup, a
“migration assistant” appears. Not much to it, it just informs the user
about the need for migration and then attempts to migrate all the
accounts and e-mails from KMail 1.x. this takes a lot of time, usually,
but hey, that’s the price of progress, right? Once the migration is
finished the user is set up and are ready to go.
What the user doesn’t know, however, is that the end of the migration
is just the beginning of fun times. During the next few days the user
will notice many entertaining facts.
Like the fact that the migration assistant does not migrate
e-mail filters. Got 200+ KMail 1.x filters set-up to help you
stay afloat on the flood of everydays e-mail activity? Tough luck,
buddy, that’s history. Good luck re-creating them all.
Like missing
e-mails
(or duplicate e-mails). Or that viewing e-mails that actually got
migrated will be unbearably
slow
at times. Some folders will just get marked as
“corrupted” (yes, these folders that were created by the
“migration assistant” itself, why do you ask?) and will cause KMail2 to
block the whole account entirely (with a nice red tint on all folder
names) until KMail2 and Akonadi get restarted…
As it turns out you can actually skip the migration and import
messages from KMail 1.x store later on, and that seems just a bit better
idea (caveat: “better” does not mean “perfect”, or even “good”).
But wait, why the heck do I need to migrate my 10GiB of e-mail
history from a perfectly working (and standard!) set-up of MailDirs at
all, just to use KMail2? And what the heck is Akonadi?
Akonadi
Akonadi is supposed to be the data engine behind all PIM (Personal
Information Manager) related content in KDE. It handles contacts,
calendars, e-mail and possibly other data (the list is growing). And it
was released as stable
as soon as it achieved more-or-less
alpha
status. At least that’s what I can tell from how well
it does the job at hand.
The fun part with Akonadi is that it has to have a database back-end
set-up. By default it uses MySQL, so when you have Akonadi, you have
MySQL instance running.
But hey, relational databases are a true and tested technology, why
not use it, instead of some internal, in-memory data store that Akonadi
would use either way? And of course now Akonadi doesn’t have to use any
internal, in-memory data store for data retrieved from such a database.
Surely, the additional abstraction layer won’t change much, at least not
to a point where it’s
evident Akonadi is
a problem.
Finally, it’s not as if keeping everything in nice, editable,
standards-compliant files on disk makes anything (backups? trying a
different e-mail client? export/import? data recovery after a failure?)
easier and safer, right?..
(un)Usability
Some problems with KMail2 are related to Akonadi; some are clearly
the fault of KMail2 itself. Of both kinds there are many.
The first biggie is the slowness. KMail 1.x
displayed the list of e-mails in a given folder instantly. And I mean
instantly. Same thing with displaying the contents of
an e-mail once clicked. In KMail2 I have to wait several seconds for the
list to appear and be usable (i.e. the list can be
visible, but not clickable). That is probably related
to the fact that e-mail data are now retrieved from Akonadi, but why do
I care? From the end-user perspective this is worse.
Now, displaying the folder contents is one thing. Moving a folder
with a few hundred or thousand e-mails from one place in a folder tree
to another – that’s a whole different game. This can take about a minute
(yes, I have actually timed it) before it’s done and the interface is
usable again.
Oh, and you get no visual cues that that’s the case – the folder list
looks perfectly normal. You can try to click a folder, only
you’ll not see the contents. You’ll also notice that your CPU fan goes
berserk and the whole interface grinds almost to a halt… and then
magically, the folder being moved appears in the place it’s being moved
to and the interface is almost usable, again – with no visual cues to
that effect.
Then there’s inconsistency. Duplicate e-mails.
E-mails that magically become unread again. Folders that have their
whole contents disappear after deleting a single out of many e-mails
they contain, only to show the missing e-mails after the user starts
pondering, frantically, when was the last time a full backup was
made…
Like the e-mails in the outbox waiting for user’s explicit “send
now”, that get sent automagically once a new Internet connection is
available. In the outgoing accounts configuration there even is an
option of configuring what should happen with messages in the
outgoing
folder. This setting is completely ignored.
Messages get sent out when KMail2 (or Akonadi?) decides so and that’s
that.
Like new e-mail accounts that, upon failure, display random failure
messages – sometimes it’s “Authentication failed”, sometimes it’s “KWallet access denied”
(even though KWallet was never used, or was explicitly instructed to
permit its use and is open), sometimes only a cryptic “Account
misconfigured” even though the account worked just minutes ago.
Then there’s mail importing. Supposedly a different,
better way to import KMail 1.x e-mails into KMail2 than the “migration
assistant”, it does a decent job of importing your e-mails from the old
KMail 1.x store and marking them all unread. One would think
that if KMail2 is importing e-mails from KMail 1.x store, it would be
possible for it to properly import also the status of messages.
Apparently, one would be mistaken.
In my case that meant I had 140k (no, not a typo) unread messages I
had to sift through and find the few messages that actually were unread.
And then mark all the rest as read – which, unsurprisingly, took a lot
of time, mainly because even marking a mail folder as unread takes much
longer than in KMail 1.x.
And after I’m done with that, there’s the joy of moving the imported
folders (conveniently put in a “KMail-Import-mail” folder) to their
correct accounts and places in the folder hierarchy. Which, as we
already know, is excruciatingly slow.
Finally, the protocol or what-have-you changes. Even
though KMail2 and Akonadi are being shipped as stable
, the
protocol and formats of the internal storage changes just a tiny bit
with some minor releases. And that means that you can have all the fun
and all the entertainment with “migrating” your e-mails more than once.
Indeed, you can be sure you will.
But apart from these important problems, there are scores of smaller
annoyances, discovery of which brings endless joy to a happy KMail2
user. I won’t be able to go into detail and describe them all – mainly
because there are so many of them. But here are some of my
favourites.
Handling of ignored threads – that’s a great feature
for mailing lists: the user marks a thread as “ignored” and all future
e-mails in that thread get automagically marked “read”. If it only
worked! In KMail2 if a thread is marked “ignored” you get 50/50 chance a
given new e-mail in it will get marked “ignored” and “read”. You can
have (and indeed, I do have) threads marked “ignored” with several
unread, un-ignored e-mails inside. Which, of course, defeats the
purpose.
But wait, there’s more! Once the user gets annoyed and un-ignores,
pretty much all e-mails in it get marked “unread”. Yay!
Password prompt for each and every outgoing e-mail.
KMail 1.x had a nice, simple and very usable feature: during sending the
password for a given account (if not stored) only had to be supplied
once; after all messages have been sent, the password was being
forgotten again. So, for 20 outgoing e-mails from a given account the
user had to supply the password only once. Usable and safe.
Of course, KMail2 improves upon this idea by asking for the password
separately for each and every e-mail.
Which wouldn’t maybe be that annoying had the password prompt been
focused properly.
Un-focused password prompt. So, you want to send
your e-mail, but the SMTP password is not stored in KWallet? No worries,
KMail will display a password prompt for you; but be careful, if start
typing your password instantly as soon as the prompt appears, your
password will land in the random other application accepting focus, as
the e-mail prompt is un-focused (and there seems no way to make it
focused by default).
So, instead of:
Ctrl-Enter
-> type-in-password -> Enter
-> sent
…you get:
Ctrl-Enter
->
find-the-damn-prompt-window-and-click-on-it -> type-in-password ->
Enter
-> sent.
Or, well, you would, if only the following was not the case…
“Send now” means “ask when to send”. In KMail 1.x
the “Send now” button and short-cut meant just that: send the message
being composed immediately. KMail2 usability experts decided that simple
actions like “Send now” are too simple and they need to ask the users
what they really want to achieve. Once you click “Send now”,
you get a nice dialog box asking you, if you really want to send now, or
maybe send layer, or cancel the whole ordeal.
To add insult to injury, there is a setting in outgoing accounts
configuration called “Default sending method”, with two options:
- send immediately;
- send later.
This option is also completely ignored.
This is completely bollocks. If the user clicks “Send now”, what
makes you think, pray tell, that they want to do anything different
than, you know, sending the e-mail immediately?.. This adds the need for
additional (and completely unnecessary) click for each outgoing message.
Usability FAIL.
“Send later” means “ask me in detail”. There is also
the “Send later” action. In KMail 1.x it simply saved the composed
e-mail directly in the outgoing mail folder, waiting for user to
initiate sending.
In KMail2 the user gets an additional dialog box containing a date
and time picker, an option to configure repetition of sending of this
e-mail (with no explanation if it will be attempted until successful at
configured times, or is the same e-mail going to be sent again, and
again, and again…), and an option to just “move to outbox”.
While I can see the potential usefulness of an option to configure in
detail when a given mail will get sent, this should be a separate
option. Users accustomed to the good old perfectly functional “Send
later” action are only going to find such a “feature” annoying. That’s
another click on every mail they send each day. That’s a lot of unneeded
clicks.
End of Rant
I have been a loyal KMail 1.x user for almost a decade. Started using
it in KDE 3.x series, I always admired the standards-compliance, the
configurability and adaptability, the feature set, the speed. It was so
good, indeed, that no other Qt-based clients gained traction. They were
unneeded. KMail 1.x simply did the job best.
Compared to KMail 1.x, KMail2 is a sad excuse of a rewrite. It’s all
KMail 1.x has never been to me – unstable, buggy, slow, unpredictable,
with daunting configuration that has options that get ignored;
nigh-unusable with the over-engineered Akonadi under the hood.. This is
very sad, as there are no other Qt-based, KDE-integrated, configurable
and advanced e-mail clients to choose from.
KMail2 has been in development for years now, and effects
are far from satisfactory. Users want to be “saved”
from it, bloggers
warn about it; the question everybody asks is “Anyone
succeeded with kmail2?”.
I am still using KMail2 now, but am on the look-out for some sane
Qt-based e-mail client. Trojitá is still too
basic for my needs, but at least it’s usable. If you have any
suggestions where to look, please do drop a line or
comment on
Diaspora.