I know that you hold up updates to the UI when processing and learning junk, and understand why.* However, it's obvious in evolution/mail/em-junk-filter.c that someone took enormous effort to separate the act of injecting messages vi sa- learn from having sa-learn rebuild it's databases. (ie, use of --no- rebuild when learning, and then later a call to sa-learn with -- rebuild). It would seem that the later action [em_junk_sa_commit_reports()] could happen in the background asynchronously. There's no need for the UI to wait for that as well, is there? AfC * [user experience report: it's a tad slow, especially if filtering new messages on first evo startup in the morning. The reason for holding updates is so that messages don't move out from underneath the user, etc on filtering, but isn't that what happens when deleting? If machine (or evo, for that matter) is busy at all, then there is a lag between pressing delete and UI repaint. No biggie. I would have thought the same applies to repaints after Junk moves. IMHO] -- Andrew Frederick Cowie OPERATIONAL DYNAMICS Operations Consultants and Infrastructure Engineers http://www.operationaldynamics.com/
Attachment:
signature.asc
Description: This is a digitally signed message part