When marking a message, a race condition can happen:
- A remote folders update is already running
- We mark the message locally and replay it remotely
- The previous remote update result restores invalid values locally
Rename `UpgradeDialog` to `DatabaseManager` since it's not actually a
dialog, move it into the APplication package. Replace old Glade UI file
with a custom built dialog since it's trivial and so we can make it
modal for a main window.
Fixes#1007
This does the following:
* Makes updating the search query a non-async call, so that apps can
call it and forget about it
* Makes updating search results only update the folder's contents
when finished, and not if cancelled
* Cancels any existing search tasks if the query is updated
* Swaps sending removed signals before inserted signals to make the
conversation viewer happier
If the current config directory is empty, go looking for config data
in other well known locations and if found, copy it all across from
the most recently modified directory.
This supports migrating config from non-Flatpak to Flatpak locations,
and release config to devel profile locations.
Fixes#326
Add dedicated methods for adding and removing accounts to simplify
callback impls and remove redundancy, ensure they check for engine
errors if an account already exists or doesn't exist.
Support API clients registering their own local folder implementations.
Use this (and the last commit) to generalise handling of the outbox by
GenericAccount by registering it when the outbox postie is started, and
when creating a map of folders that contain specific ids.
This also ensures API clients are informed of the outbox becoming
available, allowing some special case code to be removed from the app
controller.
Update to be compatible with Application.Controller composer lifecycle
changes, add matching signals so plugins can decorate composers as
they are created.
Keep track of Plugin.Composer implementation instances so that the same
object can always be returned for the same Composer.Widget instance.
Update plugin call sites.
Since plugins especially require the ability to customise a composer
ideally before presenting it, split up composer construction into two
phases: `compose_blah` methods that find a matching composer or
constructa new one, then `present_composer` to present it.
Add `composer_registered` and `composer_deregistered` signals, fired
as appropriate so other code paths (again, plugins in particular) can
hook into composer lifecycles.
Update call sites for new API and to explicitly present new composers.
Defining an interface for the composer to access application objects
and services decouples it from Application.Controller, allowing it to be more
easily unit tested.
Replace use of Application.Client and Application.Controller in the
composer and add some basic unit tests.
By defining an interface for account object access, classes that use it
are decoupled from Application.Controller, allowing them to be more
easily unit tested.
When displaying a new empty composer, only consider those attached to
the current main window. Ensure that when re-using an existing composer,
that no composers in the undo buffer are used. Ensure drafts are
displayed full-pane when appropriate. Clean up redundant parts of
the `show_composer` API a bit.
Clean up and simplify how composers are constructed. Ensure all
composers are constructed via Application.Composer. Provide a set of
APIs for constructing different kinds of composers with minimal
parameters, rather than having one method with eleventy different
parameters.
Mirror API changes in Composer.Widget by splitting `load` method up
into a method for each different composer type. Clean up internals a
bit as a result. Rename `ComposeType` enum and its values to
`ContextType` to better reflect what it does.
Most of the plugin implementation classes require instances of the
controller and other objects obtained from the application instance,
rather than the application instance itself. So pass that and the other
objects in instead of the application.
Add signals for folder contexts being added and remove, and hence also
require them to be added and removed in bulk, as collections.
Also, hook MainWindow up to use these signals rather than requiring
Controller manually manage notifying each main window of each folder
becoming available/unavailable.
Add new `FolderContext` class to encapsulate client state and policy
about a specific engine folder. Use it for display name, icon and email
count bubble policy for now.
Update AccountContext to maintain a set of folder-policy instances per
account, and convert the folder list over to using the new objects.
The `SpecialFolderType` was somewhat mis-named, since the special use
does not (in most cases) confer any special type, rather it's simply
defines what a particular folder is used /for/.
As such, rename the enum to to `Geary.Folder.SpecialUse`, moving it in
to the `Folder` class, since it relates specifically to folders, also
rename `Folder::special_folder_type` and
`Folder::special_folder_type_changed` reflect the above and not
duplicate the type name, and similarly rename
`Account::folders_special_type`.
Update the many call sites.
Remove `Geary.Folder::get_display_name` method, and
`display-name-changed` signal, and
`Geary.SpecialFolderType::get_display_name`. Add new equivalent methods
for client in `Util.I18n` and use those instead.
Pass and email object to sent-mail so that we have access to one when
notifying plugings of mail being sent and not need to convert/impement
the RFC833 message to a Plugin.Email object.
