Re: Re: [evolution-patches] Possible fix for #322016



> > Indeed - but we would be no worse off than we are today.
> 
> actually, we would... having to run filters on each folder would have a
> hefty impact on performance
> 
 
Attached is another concept patch. This time I'm in camel/camel-folder.c, where the possibility of filtering
is decided upon. The do_notify_stuff() is just a placeholder
for launching the possible new mail notifications.

This patch would not work for imap-non-inbox folders - but
I figure some extra logic could be added to add in the
case of imap and check_all being true.

We are not actually doing any filtering - we have just
found the bit of code (and hopefully the one bit of code) where filtering is normally initiated as our hook point
for new mail notification.

Clearly it would still suffer the user shuffling unread
mails bug in the imap folder scenario, but presumably not for other backends, and thus be better than the current status quo.

Karl


-----------------------------------------
Email sent from www.ntlworld.com
Virus-checked using McAfee(R) Software 
Visit www.ntlworld.com/security for more information

Attachment: 322061_t2.patch
Description: Binary data



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]