Goodbye for now, kmail

[ianseeks]

On Friday, 5 May 2017 23:53:19 BST Daniel Vrátil wrote:
> On Saturday, May 6, 2017 12:05:56 AM CEST Martin Steigerwald wrote:
> > Martin Steigerwald - 05.05.17, 16:45:
> > > - Akonadi has no notion of multitasking and background tasks – a folder
> > > synchronisation blocks interactive user requests by kmail.
> > 
> > Let me clarify that: At least within *one* resource, which is what matters
> > here. During folder synchronisation within one Maildir or IMAP resource
> > Akonadi does not respond to interactive user requests issued by KMail.
> > KMail then displays the much disliked "Retrieving…" message, but it can´t
> > really do anything else, cause Akonadi just does not respond to the
> > request by KMail in a timely manner.
> 
> Yup, that's indeed a problem. The current design of the Resource API has too
> many global states that effectively prevent running multiple tasks in
> parallel. I have several things in the pipeline that will help to solve
> this - foreign payloads (KMail reading emails directly from maildir) and
> new Resource API that will allow for multiple read-only tasks running in
> parallel. At least in the case of foreign payloads, we need notification
> payloads implemented first, but that's already underway (slowly) as it will
> also help to address the email duplication issue on filtering.
> 
> > From a user perspective this kind of behavior is not acceptable. When I
> > click a mail in the mail client, they mail client just has to do one thing
> > it has has to do it pretty fast: Display that mail. *Now*. Any second the
> > user has to wait for that simple action to be fulfilled directly
> > contributes to his or her dissatisfaction.
> 
> +1, I agree this is annoying and a bad user experience and that something
> has to be done about it.
> 
> 
> <snip>
> 
> > Aside from that Akonadi has to work stable of course – I am indeed
> > surprised to read from quite some users that it still doesn´t work for
> > them aside from the very annoyed performance related issues I described.
> > For me it is quite stable meanwhile. I am still on KDEPIM and Akonadi
> > 16.04. I read reports there has been new regressions, but my hope is that
> > developers improved it instead.
> 
> This is the really annoying part: it all just works for me. I don't know
> what I'm doing wrong, but it just works. I can't reproduce many of the
> misbehaviors and issues that users report and without that I can't fix
> them. Believe me that it really annoys me and that I'd much rather had the
> most broken setup ever that I could just analyze and fix, but I guess I'm
> just too lucky (or unlucky, depends on the point of view :-))

Is there someway we can all check release levels are all consistent with all 
the software required for KDEPIM?  It could be that all your pieces of 
software are correctly matched with each other whereas a lot of us just accept 
the upgrades and some of us may now have misaligned software releases
 
> Dan
> 
> > I have quite some hopes as I saw quite some people being very active with
> > bug triaging. I didn´t see that much of bug triaging activity since quite
> > a
> > long time. But what is also required is to fix bugs that others and I
> > reported and that are confirmed since years. Its a bit of a challenge to
> > dig out these bugs, as there is a ton of duplicates and a ton of quite
> > useless due to lacking detail or even insulting bug reports that do not
> > help a bit to improve the situation. I really hope that the bug triaging
> > activity I have seen helps to dig out those gems.
> > 
> > Thanks,


-- 
opensuse:tumbleweed:20170503
Qt: 5.7.1
KDE Frameworks: 5.33.0
KDE Plasma: 5.9.5
kwin 5.9.5
kmail2 5.4.3
akonadiserver 5.4.3
Kernel:  4.10.13-1-default
Nouveau:  1.0.15_1.1