Summary:
This reverts most of commits 39cbfe7258 ("I can haz
std::experimental::optional!") and b44642b4ec ("Rename "exp" namespace to
"stdx" to avoid conflict with exp()"), as well as other commits fixing the
build. Follow-up coding style adjustments (done mostly in commit c8e59b1a3
"GIT_SILENT: coding style") have not been reverted though.
std::optional support is only officially supported in C++17 or later, but we
were still requiring only C++14 to build unifiedmailboxagent. Switching to
C++17 in the Applications/18.12 branch requires a change to akonadi that is
only available in its master branch (ceeb4f3a, "Disable std::auto_ptr checks
in Item in C++17"), and in any case C++17 support is fairly recent
everywhere so we can just wait a bit longer before depending on it.
The discussion in https://phabricator.kde.org/D17606 is also relevant.
Test Plan: Built all code and unit tests, the same tests fail with and without this patch.
Reviewers: dvratil, #freebsd
Reviewed By: dvratil
Subscribers: kde-pim
Tags: #kde_pim
Differential Revision: https://phabricator.kde.org/D17917
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.