Years later, kmail still is not a viable email client?

Stakanov stakanov at
Mon Oct 12 10:21:43 BST 2020

In data lunedì 12 ottobre 2020 10:55:33 CEST, René J.V. Bertin ha scritto:
> On Monday October 12 2020 09:52:06 Stakanov wrote:
> >In data lunedì 12 ottobre 2020 08:42:51 CEST, Ianseeks ha scritto:
> >> On Monday, 12 October 2020 06:51:26 BST Martin van Es wrote:
> >> > The same here, but ONLY on a postgres storage backend.
> >> > MySQL and sqlite should be deprecated and postgres should be the
> >> > default,
> >> > that's all.
> >
> >Then you should consider that the way postgres requires a migration every
> >time would exceed a lot of users.
> Every time what? 
Every time there is a version update, the database have to be migrated by the 
user. Now this, if for an experienced user is not a problem, it IS a problem 
when the user is a "just user" (I do not like here any pejorative 
descriptions, as I think Linux KDE desktop should not require more user 
interaction than clicking the corresponding buttons in the normal case, here 
it would require the acquisition and acceptation of a whole bunch of concepts 
of work, which, for us is normal but, for him/her/it whatever goes here, for a 
user coming from another software world (e.g. CLI) is a mouth full.

And then you have a distribution like openSUSE 15.2 that not only had several 
blocker bugs with KDE PIM but also a bug avoiding the use, even reuse of 
existing Posgres databases. Now an "average user" would be able to understand 
were the problem is, after a system upgrade like this? 
So in a lot of cases I insist, it is not exclusively a problem of Kmail / KDE. 

> Isn't there a way around that by using a dedicated PG
> server? That was going to lead to a snarky comment about PIM becoming
> another mini OS, then I realised it already uses a framework like that.
> Isn't there a suitable database component in WebEngine that could be used?
> But really what I wonder is why every kmail user would need to have an
> industrial strength db engine backing up his/er email client. 

We are in violent agreement with this. Especially if it does not work. 

> I'm pretty
> certain that in my case it's textbook overkill. 
I never understood that choice, which made their life quite miserable I think. 

> Sure, having a gmail
> account has made me a little bit sloppy about archiving all my email in
> lots of imap folders on a local server but I still break out claws or
> sylpheed regularly for things that would be impossible in kmail (like
> mass-moving a bunch of emails to another folder) and it'd still be good
> enough for me. Does Thunderbird use a database engine in as invasive a
> manner as KDE PIM?
I do not subscribe mentioning here a provider that makes his money by 
analyzing the mails of his clients and making money out of privacy. But you 
need not go so far as to mention the evil. Take ANY provider of email. Why 
with IMAP your run into an akonadi bug when using TLS/SSL instead of STARTTLS?
Why the issues of constant reindexing, the breaking of indexes, the loss of 
data in PIM etc are appearing since Plasma 4 now? 
So we do agree that KMAIL 3 was at the time a lightweight, fast and functional 
Then we could ask if Kmail today is 
- lightweight
- fast
- functional
should we? Somehow that is already answered, isn't it.
> I do have my thoughts about a kmail version that uses shared library
> versions of the few email akonadi agents to become largely independent from
> the akonadi server architecture (which should already improve matters
> enormously if not only because you'd be avoiding dbus for most operations)
> but what good would that do? The PIM devs have already stretched themselves
> thin clutching to the current implementation and trying to get that to work
> reliably (not to say foolproofedly).
> I just keep hanging on to KDE PIM4 for as long as it works (we'll see how
> feasible it is to get to build on distri that no longer provides all
> dependencies or worse, the current akonadi version because you can't have
> the 2 versions running concurrently).
> R.
A question as I lack the technical background: why is actually Akonadi so 
ungovernable, is it the code base? The lack of human resources? 
With nearly every edition of my distribution there is a new bunch of really 
nasty bugs, seems like the hydra, one fixed two coming. You follow the PIM 
mailing list and see a lot of activity, so it is not the lack of interest. 
Some blame it on QT versions. So, I do not understand, could you educate me on 
this? I would be grateful to finally understand.  

> >And (as in the latest openSUSE15.2 where (- for reasons of the
> >distribution) -) kmail is broken beyond repair and in my case is even
> >blocking a distribution update, there was a supplemental bug that made the
> >use of postgres impossible.
> >
> >In short: kmail/kontact is unfortunately what your distribution(!) makes
> >out of it.
> >Comment of a dev: kde is not only KDE PIM.
> >
> >I guess it boils down to not exclusive responsibilities that the program is
> >so often "in the news" of the users.

More information about the kde mailing list