Kontact "unable to create calendar"

[Duncan]

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.

http://lxer.com/module/newswire/view/197664/index.html

2. Removing/Disabling The Semantic Desktop in KDE4
Running on openSUSE 13.1 (and firing up Thunderbird)

http://lxer.com/module/newswire/view/198081/index.html

3. Removing/Disabling The Semantic Deskop in KDE4
Running on openSUSE 13.1 (and firing up Thunderbird) Part 2

http://lxer.com/module/newswire/view/198639/index.html

4. Replacing KDE4 with Xfce

http://lxer.com/module/newswire/view/199397/


-- 
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.