Re: Goodbye for now, kmail

På Sat, 06 May 2017 08:29:35 +0100
ianseeks <[email protected]> skrev:
> 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,  
> 
> 

System: arch, fully updated.
Kernel: 4.10.13
Frameworks: 5.33
Plasma: 5.9.5
Kdepim: 17.04
Akonadi: 17.04
MariaDB: 10.1.22