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.
