KMail freezes after adding address to addressbook

[Duncan]

Renaud (Ron) Olgiati posted on Wed, 27 Jun 2012 16:30:14 -0400 as
excerpted:

> I have had the following several times in recent days:
> 
> - I open a composer window for a new message in KMail.
> 
> - I find the address I want in not in the address-book or recent
> addresses, so I go back to the main KMail window, hunt down a mail with
> the address I want, right-click, and choose "Add to Address Book."
> 
> Whereupon KMail freezes completely; so I have to close it, wait for "The
> window is not responding...", and restart KMAil.
> 
> An aside, when I restart Kmail, sometimes the new addresshas been added
> to the address book, sometimes it has not.
> 
> Mageia 1, KDE 4.6.5, KMail 1.13.7

OK, there's quite some history to explain here, with a not entirely 
positive result at the end, so...


The kdepim folks, who develop kde's mail, news, feeds, address-book, 
organizer, and notes applications, plus the big all-in-one kontact suite 
that contains all these roles in one, all being part of the kdepim (pim 
being short for personal information manager, think the contact suite) kde 
module...   

These kdepim devs have decided to unify the information management 
backends for all these components into a single database-based backend 
application called akonadi (which itself has several database plugins, 
for sqlite, mysql, etc).  But, this is a huge project that's taking 
several years, during which they're migrating one kdepim component at a 
time.

One of the first components to be migrated was the kaddressbook.  That 
was done for kde 4.4.  kmail wasn't yet migrated, however, so they 
created what was intended as a six-month "hack" to let kmail 1.x (as 
shipped in kdepim 4.x to that point) talk to the newly akonadified 
kaddressbook, with the intent of migrating kmail next and having it ready 
six months later, for kde and kdepim 4.5.

Except that kmail akonadification, the so-called kmail2, took way longer 
than they had hoped, and wasn't ready for 4.5 at all.  So for kde 4.5, 
the kdepim guys didn't ship a corresponding kdepim 4.5 at all, but 
instead, added a few more minor patches to the existing kdepim 4.4 series 
so it could continue to work with the rest of kde 4.5.  Thus, while most 
of kde was 4.5, kdepim (including kmail 1.x and kaddressbook) was still 
updating the 4.4.x series, which ended up at kdepim 4.4.11 IIRC.

With kde 4.6.0, kmail2 itself was mostly ready but they were still 
working on the mail migration side, for people who had lots of mail in 
kmail1 who presumably wanted to keep it into kmail2.  Later on in the six-
month kde 4.6 cycle, about 4.6.3 or so, there was finally a kdepim 4.6.0 
release with the newly akonadified kmail2 and shortly thereafter, a kdepim 
4.6.1 update, but these weren't considered fully stable yet, and in any 
case, the kdepim 4.6 series wasn't in sync with kde 4.6.

With kde 4.7, kdepim re-synced its releases with the rest of kde, so 
kdepim 4.7.0 shipped with the rest of kde 4.7.0, etc.  By this point, 
kmail2 (as part of by now kdepim 4.7) was beginning to stabilize, but 
most distros continued to ship the older kdepim 4.4.x modules still 
including kmail1.

By kde and kdepim 4.8, kmail2 had stabilized enough that upstream 
considered it fully stable and was no longer developing the minor hacks 
necessary to keep the now two years old kdepim 4.4 series synced with the 
newer kde.  Some distros shipping 4.8, meanwhile, chose to ship with the 
newer kdepim 4.8 module while others continued to ship the older kdepim 
4.4 series, now applying their own patches to keep it synced.

Current upstream-stable kde is now 4.8.4, IIRC, I believe the last 
scheduled release in the 4.8 series, and they've released a couple 4.9 
betas, with 4.9-beta2 also known as 4.8.90, which I happen to be 
running.  4.9-rc1 should be out shortly (later this week?).

That brings that side of the story upto date, but there's more to it.

As the now akonadified kmail2 was shipped and people began to upgrade, 
they weren't always happy with the results.  Initial functionality was 
deliberately very very similar, almost identical, so that wasn't the 
problem.  Stability was.  Unfortunately, the akonadi database-bridging 
backends weren't entirely stable and there were various glitches between 
akonadi and its backends, and between kmail and akonadi.  People were 
losing mail and weren't too happy about it!  Additionally, there were 
still problems with migration and people continued to lose access to some 
of their old mail in new kmail2, even to having entire mail-folders 
disappearing and having to reimport them.


I happened to be one of those people.  I had been skeptical of the whole 
akonadification thing all along, but had resolved to at least TRY the 
newly akonadified kmail before rejecting it out of hand.  So I upgraded 
to kdepim 4.6.0 and 4.6.1 when they came out during the un-synced 4.6 
series.  But after having problems with the migration and having to redo 
it, I continued to have problems with new mail.  Sometimes it would 
disappear, sometimes it would come in fine but I'd get warning dialogs 
about two copies of the same mail that didn't match.  Sometimes akonadi 
would die and I'd have to restart it to get a working kmail again.  
Sometimes it would be kmail that would die...

Somewhere about that time, after fighting with it one day, I asked myself 
why?  Why did the kdepim folks have to break a perfectly functional pre-
akonadi kaddressbook and kmail1 that already did what I want, reliably 
and well, just to try to have a unified akonadi server middleware that 
was WAY broken, and was likely to remain less reliable than the pre-
akonadi version that "just worked", for some time to come?  Well, I knew 
why THEY were doing it as it was in the blogs, etc.  What I could NOT 
properly answer is why I, as a user, had to put up with that breakage, 
and why I *WAS* putting up with it.

So I began looking for a replacement.  I prefer plain text mail to HTML 
and wasn't interested in a database-backed system as that's what I was 
getting AWAY from, so the popular Thunderbird and Evolution clients 
weren't viable options, here.

Cutting the story of picking a client short, I ended up on the gtk-based 
claws-mail.  The conversion wasn't easy altho there's several ways to 
convert the messages to claws' mh-dir format, similar in concept but not 
in detail to maildir, so a conversion was necessary.  kaddressbook and/or 
akonadi can export VCFs, which claws can use directly, but not as 
flexibily as its native addressbook format, so I found a script to import 
them as well.  I had to rewrite my 50-ish kmail mail filters to claws 
mail filters manually as I couldn't find an automated way to do that, but 
I did it.

Being gtk-based, claws doesn't fit in perfectly with a kde desktop, but 
with kde's color-scheme export to non-kde-apps option, it's close 
enough.  Claws has even more configurability in hotkeys than kmail does, 
which was a big plus, here.  And tho it wasn't on my requirements list, 
claws and the mh mail directory format is extremely easy to write scripts 
for, if you want to expand and customize functionality, which has turned 
out to be quite useful here.  And even if you /don't/ do any scripting of 
your own, the fact that the claws-mail community considers claws-mail's 
scriptability a huge feature means that CLAWS-MAIL WON'T BE DOING THE 
SAME DATABASE BREAK-THE-WORKING-MAIL-CLIENT THING ANY TIME SOON!!

All in all, I started out happy with claws-mail, but the more I use it, 
the happier I am with it and the gladder I am that I made the switch.  
Now I'm just regretting not making it sooner!  =:^)


Now to be fair, since I switched to claws-mail right about the beginning 
of kde 4.7, I really can't say personally how the akonadified kmail2 has 
improved since then.  However, based on posts to the lists, a lot of 
people are still unhappy with it, and many are switching to other 
clients.  Some switch to evolution or thunderbird and find their more 
mature database solutions work for them.  Others end up on claws-mail 
like me.  Some end up on a different client or (horror of horrors to me, 
but if it works for them...) simply doing webmail.  And of course there's 
some that find at least 4.8+ kdepim's kmail2, or the kontact suite that 
includes it, stable and useful as it is.


Now back to you.  The distro and version you're on is still running a 
year-old kde 4.6, with the old kmail1 which means they year older than 
that kdepim 4.4, so you're running a two-years-outdated mail solution 
that in that form is a dead-end, since kmail1 is no longer being 
developed.  You're also dealing with the intended-to-be-6-month hack 
bridging the already akonadified kaddressbook of kdepim 4.4 with the not-
yet-akonadified kmail1... now two years later.  So much for a six-month 
hack!

But that hack does partially explain the problem you're having.  It 
wasn't meant to be perfect, just a hack to last what they /thought/ was 
going to be six months until they got their preferred solution, the 
akonadified kmail2, up and running.


So here's the deal.  Short term, you basically deal with the hack.  If 
that means closing kmail and restarting it once in awhile... I guess you 
live with it.


Longer term... probably by the time you upgrade kde, which probably means 
when you upgrade from Mageia 1, you have a decision to make.  You have to 
decide whether you want to try the new akonadified kmail2, and hope it 
doesn't eat mail, etc, or whether instead you want to switch to something 
else.  Obviously you know the choice I took from the above, but that 
doesn't mean it's the choice that's best for you.  Your decision, but now 
that I've laid it out, you do have some time to think about it before you 
have to act.

If you DO decide to switch to something else, you might want to actually 
do it before your big upgrade to a newer Mageia and kde.  That way, you 
won't have to worry about both upgrades at the same time, and you can 
already be up, running, and comfortable on your new mail client, when you 
do your kde and presumably mageia upgrade.  As with the decision to 
change at all, my choice, claws-mail, isn't necessarily the right one for 
you.  Particularly if you like webmail, thunderbird may fit your needs 
very well.  And if you want to try a suite and don't mind having gnome 
installed too, evolution may be a good choice.  They both do use 
databases, but they've been using them for years now and as such their 
database backend solutions are much more stable than akonadi is at this 
point.

Which of course demonstrates that akonadi COULD be a very reasonable and 
stable solution for kmail... 3-5 years from now!  If you're willing to 
live with the bugs, etc, as it matures, sticking with it may be a good 
choice, and it's certainly the easier choice as the upgrade route is more 
direct.  But it will mean a certain bit of unstableness and bugs in the 
mean time.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.