Re: [gentoo-user] Anyone succeeded with kmail2?

[Mick <michaelkintzios@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 3891 bytes --]

On Thursday 03 Jan 2013 10:33:52 Alan McKinnon wrote:
> On Thu, 03 Jan 2013 09:43 +0000
> 
> Peter Humphrey <peter@humphrey.ukfsn.org> wrote:
> > Hello list,
> > 
> > When kmail was upgraded to 4.9.3 last month it made a complete hash
> > of my e- mail system. In the end I moved my user out of the way and
> > created a new user. Importing the e-mails from a backup of the old
> > version omitted large numbers of e-mails, including a lot of complete
> > folders. I also noticed that kmail had not created a trash folder.
> 
> So the kdepim devs STILL haven't fixed that one? Oh dear.
> 
> tldr; longish post. Short version: Use something else. It's mail, not
> software magic.
> 
> I ran into something much the same long ago with kamil2
> around the 4.3 or 4.5 era. Imports wouldn't work, akonadi was displaying
> essentially random mails in random folders in no special order, and I
> was losing mail.
> 
> Eventually, after much physical and spiritual pain, I figured that what
> was really happening was probably akonadi importing the mail to
> $SOMEWHERE and $AT_SOME_RANDOM_TIME would index it properly; it would
> do this on the basis off $WHEN_IT_FELT_RIGHT_TO_DO_IT.
> 
> This trick works awesomely well for caching thumbnails of my video
> collection for xbmc. It works less well for my mail. It's disastrous
> when the whole process is not documented, when the user has no
> visibility into it and no defined way of seeing what's going on, not
> even a progress meter. The traditional way of handling such
> asynchronous indexing problems is to provide an option where the user
> can force a re-index and the system will just chug along doing it
> displaying progress. If the mail app suspends itself while doing this,
> well that's fine, at least it ends in a reasonable time. But, kdepim at
> that stage had no such option.
> 
> One other thing I discovered back then: if I killed akonadi & kdepim
> and rebooted out of sheer frustration, it would *throw* *away* all it's
> temporary files form $SOMEWHERE as above and corrupt it's own database.
> Leading to lost mail. If you just leave the damn thing alone for ages
> and ages it eventually sorts itself out, but you can't see how far
> along it is.
> 
> Such shoddy alpha-quality software shipped and billed as enterprise
> production-ready was more than I could bear, so I just switched mail
> client to claws-mail.
> 
> On 4.9.3 you are still experiencing something similar. Hmmm. Indicates
> to me a high probability of a systemic problem with the projects
> approach, something that is unlikely to ever get really fixed. In my
> opinion kdepim2 is vastly over-engineered and an attempt to solve a
> problem that does not actually exist. I recommend you use a different
> mail app.
> 
> As I mentioned in the tldr, it's a mail app. There are many mail apps
> and none are super-special.

Thankfully, I'm still on kmail-1.13.7 and I am dreading the time that it will 
no longer be available.  I've used kmail for so many years now that everything 
else I tried has been a great disappointment for me.

Last time I tried to upgrade to kmail 2 some time early last year (for the 4th 
time) it made exactly the mess experienced by others, like:

- duplicate/multiple messages when I tried to delete them
- missing/disappearing messages
- inability to show anything other than the Inbox folder on IMAP4 accounts

I could swear that I waited for it to sync/resync, but I didn't leave the box 
running overnight to see if that would fix this problem.

In all but one box I am not running a full KDE enchilada, so I don't know if 
this has something to do with it.  I just hope that new devs will eventually 
take over this KDEPIM farce and something sane will surface for those of us 
who still want/need to use a mail client.

-- 
Regards,
Mick

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3898 bytes --]