There's now a list of inboxes at the top of the sidebar if you have more
than one account. It gets the default selection if possible, so you
never have to see all the folders of your accounts if you work entirely
out of your inbox.
Geary originally only dealt in email messages, and so the original
classes' names reflected that. When we switched to
conversation-based views, those names were not changed, making the
code slightly difficult to understand. This converts those client
classes into Conversation* names.
YorbaApplication's 'exiting' signal now allows callbacks to cancel the
edit. GearyController now keeps a list of all open ComposerWindows, and
listens for YorbaApplication's 'exiting' signal. When the signal is
received, GearyController warns the user about each open ComposerWindow
with unsent text. If the user cancels the closing of any of these
ComposerWindows, GearyController cancels the edit.
Unsolicited server data is how the server can notify of changes (adds, removes)
while the client is pulling data for an unrelated command. This patch catches
that unsolicited information and propagates it via signals.
Also some small fixes dealing with local/remote positional addressing in
EngineFolder and a bug that was introduced by the add/remove notifications in
MainWindow.
Merging in additions to an email's fields in MessageTable could result in many
serialized SQLite operations that were independent of each other. This change
(a) parallelizes them via NonblockingBatch, and (b) reads the messages existing
fields and strips out writes to fields it already holds. This is legal because
none of the current fields in MessageTable are mutable on the server, but is not
allowable for ImapMessageProperties because they are.
Also, there were some naming inconsistencies in NonblockingBatch that are
corrected here.
Before we were fetching the entire message body (including attachments) to get the
preview text. This patch now offers the ability to fetch a small (128 byte) preview
of the email.
Also, since this ticket is about speeding up performance, I've introduced NonblockingBatch,
which allows for multiple async operations to be executed in parallel easily. I've added
its use in a few places to speed up operations, including one that was causing the lag
in #3799, which is why this commit closes that ticket.
This incorporates much better duplicate detection in the local database, using both RFC-822 Message-ID as well as IMAP metadata (internaldate, RFC822 size) to determine if a message is already stored in the database. Very useful when a message is stored in multiple folders, or an already-downloaded message is returned to a folder it originated in (i.e. INBOX).
Also some minor fixes to listing email by EmailIdentifier which save a roundtrip to the server for certain edge cases.
Conversations now fully monitor the Folder for both additions and removals of messages.
This exposed a couple of bugs in the database code, which are fixed here as well. I also
used this opportunity to clean up some of the internal Conversations code, simplifying Node
management. #4333 will be a big boost here when implemented.
addressing.
Positional addressing is a nightmare for a lot of reasons, especially keeping positions
up-to-date as the Folder mutates. Now, positions are returned with the email but for
advisory reasons only, and do not keep up-to-date. It is expected that a client will use
positional addressing to "bootstrap" the application's data store, then use EmailIdentifier
addressing to traverse the Folder's contents.
Prior commit did not completely fix the problem in the case where a remote folder open took
a long time. This bulletproofs the solution, but does mean that there will be some
situations where FAST messages return with EmailLocations that radically change in the near
future. As the contract allows for any changes whatsoever, this is acceptable.
Eric spotted a bug where messages retrieved via FAST (i.e. straight from the database) were
not assigned their proper EmailLocations, which has a lot of ramifications when more emails
are being requested.
message (email), suitable for decoding a message off the wire or converting a
human-generated form into something suitable for pushing on the wire via SMTP.
This bug was exacerbated by rapidly switching between folders. This patch introduces a
Cancellable to most of the requests the client performs so it can cancel old requests when
the user switches folders. This fixed some issues but exposed others.
Testing this demonstrates another bug: #4233
This adds a new flag when listing messages, FAST. This indicates that the caller wants
messages that are immediately available to the Folder, avoiding a round-trip to the server
(or even disk) if possible. Not all folders will support FAST, but it can be used (as it is
now in the client) to quickly populate the message list and then initiate a connection in
the background to get the straight dope.
