This speeds up startup time immensely, probably due it matching the
the filesystem's or Linux memory mgmt's page size. It's also
expected that this will improve database performance in other ways,
as the default was 1K, meaning potentially more I/O than necessary
for standard operations.
Db.VersionedDatabase.open_background() will do open() in background
thread. ImapDB.Database now uses upcalls to schedule progress
monitor updates and a polled callback to pump the event loop.
A couple of queries (at least the search blacklist query and the folders
for each email query) weren't respecting the flag in
MessageLocationTable that means we should treat the row as if it didn't
exist. This was causing problems where a draft that was also a search
result would keep being duplicated in the search results as you typed
more in the draft. The cause was that the removed signal was fired
after the message had been marked as removed, but before it was actually
deleted, so it was still being found in the search even though
folderless emails are blacklisted.
* Increase the size of the spinner; fix#7184
* In the event of an error sending a message, display text in the status
bar indicating as such (and display a notification too); fix#7481
* Display a status bar message and spin the spinner when sending;
fix#4629
* Re-add the sound played when a message is sent; fix#5429
This takes advantage of Outlook.com's new IMAP support, meaning
Geary works with Outlook.com, Hotmail, and Live.com users.
Because Outlook.com doesn't support UIDPLUS, some features
(in particular, draft auto-save) is unavailable, as is the
ability to use its Archive folder directly.
This patch fixes a couple of bugs that occur when a server doesn't
support UIDPLUS. Also fixes a use case with UID increment/decrement
that caused a flag watcher bug due to ImapDB.Folder always
returning the same email if only one was present in the folder.
ImapEngine.GenericFolder.internal_close_async() was hanging due to
the ReplayQueue never closing. This could occur if there was a
hard error (i.e. network) while opening the Folder. In essence,
this hung Folder.open_async(), which put the client into a bad state.
Now the ReplayQueue doesn't hang and is flushed if a "clean" close,
while outstanding operations are dropped if closing due to an error.
This also includes some small fixes in ClientSessionManager to
prevent a hang due to mutex reentrancy, and a State problem in
ClientSession that is unrelated but bad enough that it should be
included here.
Engine validation now takes options flags indicating if the
validation is for adding or editing an account, and if the
network connections need to be checked.
It was a good idea in theory to trigger an append when search results
are first added, but this hits the conversation monitor too hard, which
can't easily handle large appends (ticketed at #7464).
This also updates the conversation monitor to listen to the new inserted
signal instead of looking at count-changed.
This handles the case when an image is specified in the message
with no Content-Disposition; in that case, use the "natural"
disposition for the client (i.e. images are inline, other types
are attachments).
If the database's current schema version does not have a corresponding
schema file in the schema directory, throw an Error and report it to
the user. Most likely this means the user is trying to run an older
version of Geary against a newer database.
While working on #7345, I grew dissatisfied with how Geary.Attachment
was implemented. It knew too much about imap-db's internal workings,
so I've broken it up a little bit. It's now an abstract base class
completed by ImapDB.Attachment, a private implementation class.
This corresponds with the coding patterns used throughout the
Geary API.
The database is now tested for corruption at startup. If a problem
is detected, one of three error messages are displayed in a dialog box
(corruption, permission problems, and "general error").
With this, you can search for something like
chaz@yorba.org
and due to the tokenizer, it'll end up like
"chaz yorba org"
which at least means the tokens have to appear sequentially.
Previously, it would appear like
chaz yorba org
which lets them appear anywhere in the message; clearly not what you
wanted.
Folder now offers an "email-inserted" and "email-locally-inserted"
signal to indicate when email has been added (or discovered) but
is not added to the top of the message vector. SearchFolder and
ConversationMonitor may be able to use this better in the future.
Just experienced a crash in the SmtpOutboxEmailIdentifier
constructor trying to get its own type name. Past experience
has shown that calling into GObject (or GType) in the constructor
before calling base() is dangerous, so changing this to a flat
string.
Imap.Folder is now more paranoid about checking if the ClientSession
is available before performing an operation. The ReplayQueue does
a better job of flushing pending commands when closing the Folder.
This optimizes the search query itself, and also how we get the results:
instead of turning around and selecting the full row for each resulting
id, we simply pull out the id and internal date and that becomes the new
SearchEmailIdentifier. This new class also lets us more properly order
EmailIdentifiers everywhere else.
This was recently changed for the double-archive problem and now these
ReplayOperation calls can happen at any time, not just after the
location execution, so they need to do null checking every time.
I noticed the double-archive problem again just now. Looking at
the log, it took even longer than 250ms for Gmail to notify of the
EXPUNGEs after the append, so this patch increases the delay to a
full second.
It may be that this delay strategy is only pushing the timing hole
around, but until we can come up with a better solution, it'll have
to do.
Two bugs are fixed in this patch:
(a) Freemail's XLIST returns the Inbox's name in Ukranian. This
is a problem when doing a direct list (i.e. XLIST "" "Inbox") to
get folder properties. This is fixed by using LIST whenever listing
Inbox.
(b) Freemail returns FETCH BODY[] header fields back in an
indeterminate order. Previously the IMAP stack relied on a string
comparison to match up the response with the request. New code
now properly (but painfully) parses the BODY[] response, obviating
the need for FetchBodyDataIdentifier.
The slight pause (sometimes up to 2s on my machine) was due to some
CPU-intensive work occurring during folder normalization. Some of
the work can be done in a background thread (using the new
Nonblocking.Concurrent class), but some of the problem was simply
that the Deserializer's priority was too high, causing it to block
UI events when it was busy (such as requesting a lot of UIDs from
the server).
This was also developed while working on #7426. Before, the IMAP
implementation walked and built-up strings using unichars. However,
IMAP guarantees 7-bit ASCII in all data transfers (except in literal
data, which isn't processed at this level), so use old-style ASCII
processing of request and response strings, which is slightly more
efficient.
Because full folder normalization is avoided whenever possible,
need to go back to marking messages as removed in the database (vs.
just in memory) so if messages are not removed on the server (or
the response was not received for some reason), the folder is seen
as "dirty" and a full normalization is processed.
This is a tricky timing bug triggered by Gmail sending EXPUNGE and
EXISTS notifications in a particular order with a slight timing delay
between them.
Normally Gmail will send one or more EXPUNGE notifications followed by
EXISTS to finish up a list of removal notifications. Even if the
client sends an APPEND followed by STORE/EXPUNGE, the EXPUNGE
notifications are first.
However, if the client STORE/EXPUNGEs on one connection and a new
message arrives from another (or via SMTP), Gmail will issue an
EXISTS (append), wait 250 msec, then issue the EXPUNGE(s). In
that 250msec delay, Geary has already turned around and requested
the new message, which no longer exists at the reported position
because the EXPUNGEs (which have not arrived yet) have shifted it
downward.
The solution is to pause when notifications come in so all can
be accounted for, shifting positions as necessary.
This should take care of the problem, exacerbated by multiple Inbox
folders being allowed in the root of the FolderTable. Much more
strict in this patch about folders named "Inbox".
