Goodbye for now, kmail
Martin Steigerwald
martin at lichtvoll.de
Fri May 5 23:05:56 BST 2017
Martin Steigerwald - 05.05.17, 16:45:
> - Akonadi has no notion of multitasking and background tasks – a folder
> synchronisation blocks interactive user requests by kmail.
Let me clarify that: At least within *one* resource, which is what matters
here. During folder synchronisation within one Maildir or IMAP resource
Akonadi does not respond to interactive user requests issued by KMail. KMail
then displays the much disliked "Retrieving…" message, but it can´t really do
anything else, cause Akonadi just does not respond to the request by KMail in
a timely manner.
From a user perspective this kind of behavior is not acceptable. When I click
a mail in the mail client, they mail client just has to do one thing it has
has to do it pretty fast: Display that mail. *Now*. Any second the user has to
wait for that simple action to be fulfilled directly contributes to his or her
dissatisfaction.
I didn´t try Claws Mail yet, but I expect it to get this right and this is a
major advantage of any mail client that gets this right.
Despite all what I wrote, I am still with KMail, cause up so far I found
nothing as good as KMail regarding usability and set of features. KMail is
just my mail client, and I want to continue to use it. Due to fast hardware
and aggressive MySQL tuning I have response times from instant to maximum of a
few seconds usually. On synchronizations of very large folders this can be
exceeded already. And sometimes I still loose my patience and do the usual:
- akonadictl stop
- check whether mysqld is still running
- if yet, then send SIGTERM to the process till it really is gone (I know it
does help to send SIGTERM mutiple times, but I tend to get emotional at that
time)
- tell KMail to start Akonadi again
This usually helps to be back to immediate responses again, as Akonadi then
has stopped whatever it started working on, whatever it deems to be more
important than to respond to my interactive requests.
But the truth is:
If the user has a request, i.e. clicks something in KMail, then there is
nothing else that can be more important than that. The user is king or queen
and nothing else matters if she or he has a request to fulfill. As long as
Akonadi doesn´t get this right, it will continue to the dissatisfaction that
make people leave.
Akonadi really needs to get this right. Any design that doesn´t take this into
account in my eyes is fundamentally broken. I think also for Munich it is
absolutely essential to get this right.
Aside from that Akonadi has to work stable of course – I am indeed surprised
to read from quite some users that it still doesn´t work for them aside from
the very annoyed performance related issues I described. For me it is quite
stable meanwhile. I am still on KDEPIM and Akonadi 16.04. I read reports there
has been new regressions, but my hope is that developers improved it instead.
I have quite some hopes as I saw quite some people being very active with bug
triaging. I didn´t see that much of bug triaging activity since quite a long
time. But what is also required is to fix bugs that others and I reported and
that are confirmed since years. Its a bit of a challenge to dig out these bugs,
as there is a ton of duplicates and a ton of quite useless due to lacking
detail or even insulting bug reports that do not help a bit to improve the
situation. I really hope that the bug triaging activity I have seen helps to
dig out those gems.
Thanks,
--
Martin
More information about the kdepim-users
mailing list