Two problems: binding changes in Gtk.TreeStore.remove() and it
appears that Vala is now using the type_id field in the VAPIs
(before it seemed not to be used anywhere).
This major patch switches Geary to using XLIST whenever possible
to identify special folders. Because it's now possible for special
folders to be identified by MailboxAttributes and/or hard-coded
paths, needed to find a flexible system for the various flavors to
identify them as such.
Courtesy Timo Kluck.
An old bug was causing duplicate folders to be created in the
database. Fortunately the duplicate folders will, due to other
logic, not become the parent of other folders or hold messages.
This patch removes the duplicate folders and prevents them from
being created again.
This work is necessary in preparation for #3704, which uses the
database a little differently in regards to folders.
Adds new mail notification via libnotify for new previously-unseen
messages. Various minor bugs fixed in here as well that were
relevant to this operation (including notifying of locally
appended messages during folder normalization and reusing Folder
objects inside Account).
Squashed commit of many patches that merged Eric's outbox patch
as well as additional changes to upgrade the database rather than
require it be wiped and some refactoring suggested by the Outbox
implementation. Also updated Outbox to be fully atomic via
Transactions.
Deserializer needs to perform a read on literal data even if it's
zero bytes to properly send events to the state machine, but
recent changes caused the Deserializer to push an EOS event in
that case.
- Give the user a "remember password" option that they can uncheck if
they don't want Geary to remember their password. You've seen most of
this part of the patch before, aside from a few bugfixes.
- Display a nicer dialog when re-prompting the user for their password.
This only shows (editable) fields for "password" and "remember
password" by default, with (non-editable) fields for "Service" and
"Real name" available in an expander.
- Fix a crash that occurred whenever an account is connected when there
was previously another account (or the same account) connected.
A timing window opened in the recent changes to Deserializer that
allowed for a ServerData "received" signal to be fired before the
ClientConnection.connect_async() call completed. This is to be
expected in a heavily asynchronous library. The ClientConnection
"connect" signal, however, is guaranteed to be fired before the
"received" signal, so that is used to synchronize some state in
ClientSession needed for login.
In #5321, the problem causing the connection close to hang was how
the Deserializer dealt with EOS and I/O errors. They were being
handled ad hoc outside the state machine.
This patch adds EOS and ERROR events to the state machine. I
tested it last night against a version running without these changes,
and both were able to deal with connection loss without hanging.
This morning I saw that my Inbox connection had not been
reestablished. Looking at the debug log, I could see that the
Deserializer hung at close. This patch closes two holes where
the Deserializer might stop receiving input and not signal the
closed semaphore (which synchronizes the close_async() caller to
wait until the Deserializer has completed all I/O, necessary to
prevent a GLib crash in a background thread).
All IMAP commands now have a timeout which, if triggered, causes
the connection to be forcibly closed. ConversationMonitor will
reestablish connection and start a re-sychronization.
Currently Geary creates two wasted sessions every time it tries to
validate account information against the server (in addition to the
session it actually uses for validation). This patch prevents those
wasted sessions from being created, which allows the user to attempt to
login many more times before Gmail kicks them off the server.
Previous commit:b092e407 fixed this problem but didn't clean up the
db of users who'd saved the incomplete PROPERTIES data. This patch
will catch when properties are unavailable, forcing the engine to
pull them from the network and repair the hole.
Caused by an edge condition where the folder is empty in the local
store and no normalization occurs, meaning the PROPERTIES of email
must be pulled by the ListEmailOperation.
Also cleaned up some code in Sqlite.Folder ... the logic was a tad
messy.
This morning I noticed that connection reestablishment failed.
It appears that the connection failed right after it was opened.
Looking at the conversation monitoring code, it's possible that
the handler to catch the close signal may not be hooked up when
the aborted close happens. This closes that hole.
