It wasn't implemented and would not work properly for newly-added source
collections for instance. And it does not make sense to keep track of when
was the last time we saw an event from a particular source collection.
This enabled the "Move to Thrash" action in KMail, which causes the
Item to be moved from its source collection into a trash collection.
We get notified about that (we see it as a Remove due to translation
in Monitor) and just unlink the Item from our Unified Mailbox.
We still default to Inbox, Sent and Drafts but users now can defined
their own unified mailboxes or they can exclude (or include) additional
collections into the default unified mailboxes.
I think reacting to changes does not work properly, the notification
subscription must be checked.
The BoxManager needs likely another look, probably could be smarter
and maybe built on top of custom Monitor (for Collections) to better
react to changes.
The agent (which in reality is a Resource in order to be able to own
Collections) creates Inbox, Sent and Drafts virtual Collections and links
all Items from real special Collections into them. It listens for changes
in the source collections and updates the virtual Collections accordingly.
This is just an initial proof-of-concept, the plan is to allow users to
define custom unified mailboxes with the special Collections being only
the pre-defined defaults.
This agent will likely require some changes to KMail to allow better
interaction with the virtual Collections (e.g. deleting emails from the
unified mailbox should actually trigger Move to Trash action on the
source Collection).
The initial linking is very fast (even with a collection of ~80k emails)
but the brutal notification storm then triggers some asserts in ETMs
and freezes all apps for a decent amount of time due to ItemSerializer
parsing all the Items in the notification, so this will have to be
optimization in Akonadi.
Yuri Chornoivan
Laurent Montel
l10n daemon script
Daniel Vrátil