When another folder is selected, the Inbox folder is still open
for monitoring and notifications. However, its ConversationMonitor
is destroyed when the folder selection changes, which is the
mechanism that performs connection re-establishment if the connection
dies. Thus, if the Inbox connection dies while another folder is
selected, new Inbox messages are not received.
This fixes that problem by maintaining an Inbox ConversationMonitor
at all times.
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.
This is an attempt to break apart the client into suitable
categories. The ui directory was being overloaded with every
possible UI class. This attempts to give some organization going
forward as well as make it easier for new contributors to wade
into the code.
Fortunately this could be coded without breaking string freeze.
Also, added code to handle situations where the To: or From: lines
would be blank if not availble in forwarded message (but Subject:
is always shown, even if blank).
The logic for moving the selection after an archive/delete relied
on Gtk.TreePaths being ordered monotonically, which is not
guaranteed.
It looks to me that the default behavior for Gtk.TreeView works
just fine. However, there might be regressions due to removing
this logic. More testing will help.
The refactoring to allow for separate usernames and passwords
removed a key workaround and re-enabled pipelining for Dovecot
servers. IMAP pipelining won't work until #5224 is completed.
Closes#5778, Closes#5777, Closes#5703
The problem was sending the IDLE command in the same buffer as
the prior commands. This causes Dovecot to hang (perhaps the
connection state machine is transitioning to IDLE too soon).
The solution is to flush the prior commands then send the IDLE
command in its own buffer.
This fixes a nasty little bug I noticed today where Geary would
load new messages from the server, but if you closed and re-opened
Geary, they wouldn't appear until it had connected to the server
again.
It turned out the local database wasn't updating the last_seen_total
value (very important when loading messages before connecting to
the server) due to an issue where SQLite cannot bind NULL to WHERE
clauses in prepared statements.
./configure will autodetect xgettext, and if available, "make pot_file"
will generate the po/geary.pot.
This does *not* include intltool support, so the .pot file only
contains strings from the source files.
The new notification subsystem was causing a partial set of fields
to be pulled from the remote and stored in the database in such a
way that the ConversationMonitor might not continue loading the rest
of the message, therefore making it unable to add to a Conversation.
This change ensures that all messages in a minimum window (from the
most recent to that count) are loaded and in stages (local only when
first opening, a full load when the remote is ready).
This also closes#5689 and closes#5726, which I believe are other
symptoms of this problem.
Previous commit exposed a bug caused by moving some of the client's
resources in the source tree. Since much of the client's resources
are stored off the source root directory, it doesn't make sense to
special case the .desktop file and the GSettings file and place them
in the client source itself. This moves them out and makes the
appropriate changes in the CMake files and source code.
This rather large patch allows separate IMAP and SMTP credentials
and separates the user's credential username from their email
address. Additional work in this patch includes fixing some minor
protocol bugs in the SMTP stack to work with Postfix, refactoring
the Geary.Engine interface to stop issuing plain strings for
account names, and removing the Geary.EngineAccount abstract class
which was growing unnecessary with each passing day.
The problem is that the geary.desktop file is installed to
/usr/local/share/applications when PREFIX is /usr/local, which is
not monitored by GNOME. However, this is okay as long as the
desktop update util is run. It is, but it was being run *before*
the .desktop file was installed. This patch fixes it so the update
is run after, which is also how we do things in Shotwell.
