When the remote re-opens, new messages may have become available that
could be added to the conversation set if the window is not yet full.
Thus always check whether a fill operation should be queued.
Two of my account's databases had duplicate inboxes which were not being
removed by the existing workaroud, this updates it so that they are.
I had removed the duplicate from a third account ages ago and it hasn't
come back since, so maybe the underlying problem is gone, but the
correct fix would be to move this workaround to a migration and add a
uniquness constraint on (parent_id, name).
After switching to DBus activation, we need to ensure that a controller
is present when arbitrary GApplication actions are executed so a
main window also exists. This lead to a deadlock on first run since
when the application was activated, it would be in the middle of
constructing the controller when it showed the Accounts Editor, which
would block since it would also try to construct a controller.
This fixes the deadlock by moving the first-run check to the
application, outside of the lock.
In InsertOperation, check that more are needed and if not, only insert
if above the last email in the folder window, so we don't blow out the
window size when large inserts coming in (e.g. from the search folder).
When search results are updated in response to a serch query changing,
there can be both very large (up to 1000, the current hard-coded limit)
email and hence converstion inserts and removals in the search folder.
This splits up these large ops that execute multiple times in batches
(currently n=20), so that the main thread has a chance to breathe while
handling the updates.
Make ImapDb.Account::strip_removal_conditions use a single RO txn and
manually load flags from the message row when looking up email to filter
out, to keep overhead as low as possible.
This fixes search/star and archive/select all conflicting, cleans up
mark read/unread conform to the HIG, and updates the help overlay and
fix some problems with it.
Using a spin lock meant that if an IDLE was cancelled while it was being
sent it wouldn't actually be cancelled until something else came along.
This would commonly cause a deadlock, since higher level code would be
waiting for the command that was queued that caused the IDLE to be
cancelled in the first place.
Add a ReplayQueue checkpoint after queing the empty op to keep the
folder open long enought that all flag updates and expunge notifies are
received and processed.
To support more deterministic folder synchronisation, add means to
flush all pending server notifications and a checkpoint operation to
be able to determine when they have been processed.
