Re: [kde] Kontact "unable to create calendar"
- Date: Sun, 9 Mar 2014 13:29:58 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde] Kontact "unable to create calendar"
huw posted on Sat, 08 Mar 2014 22:52:38 +0000 as excerpted:
> It raises a question in my mind. I will probably sound like yet another
> whiner and I'm sure it's been said before on this list, but why oh why
> have the KDE devs persisted with Akonadi? I know that I'm far from
> alone in having experienced multiple issues with it, when Kmail1 worked
> just fine. There's just bug after bug after bug, problem after problem.
> Every solution, every temporary workaround, has involved fiddling deep
> within config files for this most maligned of daemons. I strongly doubt
> they've had a single email from someone thanking them for the
> life-saving addition of this problematic, hellish...whatever Akonadi is.
> What benefit has it brought anyone?
Well, (as Kevin points out) akonadi helps integrate your kontact calendar
with the system tray calendar, which you mentioned you liked, along with
all the rest of the PIM-area integration it does, so...
But from the context, you were thinking more specifically about
akonadifying kmail specifically. To be honest I am /quite/ sure the
kdepim folks didn't expect all the problems they've had on the kmail
akonadification side, and as you point out, the other bits haven't had
the same problems and do seem to provide some benefit. In hindsight, I
don't know whether they'd try the kmail integration again and just give
it LOTS longer, or avoid that, given all the problems it has caused.
However, once they started down that path, it wasn't something easily
reversed. Kmail-1's code had, from what I've read, become a bit of a
spaghetti heap, and wasn't so easily maintainable any longer... and that
problem hasn't gotten any better on its own. Meanwhile, kmail2 offered
the opportunity to strip a lot of that code out, replacing it with a new
and mostly shared-code backend in the form of akonadi. So they stripped
out the old code and replaced it with much simpler akonadi interfaces,
letting akonadi do most of the hard work. Except... well, the mail side
of akonadi has had all these unanticipated bugs that they've now worked
YEARS to fix, and it has always seemed that fixing those last few bugs is
*MUCH* easier than either basically starting over from scratch with a new
back-end implementation once again, or going back to the now several
years unmaintained and un-updated already spaghetti code, that's such a
monster to actually do anything with.
Meanwhile, from another viewpoint, a lot of the kdepim funding has been
coming from one particular company, that has an integrated server-side
product with which apparently kontact (including kmail) actually works
quite well. The mail side of it is IMAP based, and from what I've read
the particular style of IMAP it uses is the /one/ form of mail connection
that akonadi is actually rock-stable on/with. A lot of Linux development
is funded by big corporations and us little guys generally get the
benefit of it, but every once in awhile something like this comes along
where there's so /many/ problems, and the folks paying the bills do tend
to get priority at having their problems fixed, leaving the rest of us
out in the cold if there's more problems than funding/time to fix them.
For another completely independent take on that particular angle of the
problem, it's worth looking at the recent series of LXer articles on what
to do about kmail, from a guy who has been on an opensuse LTS release
that still had kmail1, that's about to go out of support, so he's looking
at what to do now that he's about to lose his kmail1 support and yet
finds kmail2 totally unsuited to his needs. What he says about kde4's
tip toward the semantic desktop and akonadi, and how it all seems to be
tilted toward the big corporate side of things, really does seem to
explain things. Unfortunately, it seems kde is about to lose him to xfce
over this entire thing. (Fortunately I'm running gentoo and have been
able to strip kde of the semantic-desktop aspects, but for kdepim which I
thus entirely replaced, using the appropriate USE flags. But running a
scripted-build-from-sources distro like gentoo, just to properly kill
semantic-desktop at build time, isn't for everyone, including him.)
1. KMail Complexity - and a little Patience.
2. Removing/Disabling The Semantic Desktop in KDE4
Running on openSUSE 13.1 (and firing up Thunderbird)
3. Removing/Disabling The Semantic Deskop in KDE4
Running on openSUSE 13.1 (and firing up Thunderbird) Part 2
4. Replacing KDE4 with Xfce
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.
More info: http://www.kde.org/faq.html.