Replace open method with an async ctor, so we can make a few properties
non-null by default, and callers need to call one less call. Make
destination folder configurable, and require email flags passed in
via the ctor, not every time when saving.
When the drafts folder is selected, and a draft is being edited, and
that dis discarded, there is a race between the composer disappearing
(and hence the draft being shown again) and the draft itself being
removed from the folder. Attempt to check for this and avoid reporting
the problem.
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.
Expect the same variant format for the `show-folder` and `show-email`
application actions. Use existing email and folder store factory
lookup methods for these. Update DesktopNotifications plugin to simply
pass variant values from plugin classes through to notifications.
Implement these in Application.EmailStoreFactory's implementation of
the interface.
This switches the variant format used to `(account_id,email_id)` to
match that used for folders, and so a folder doesn't need to be
specified when showing an email.
This breaks opening email from desktop notifications, but that will be
fixed shortly.
Only signal folders available/unavailable if non-empty when adding or
removing accounts, avoid producing two collections when signalling, and
fix removing folders from the store before signalling that they have
been removed.
Move implementation and management of Plugin.Account instances from
FolderStoreFactory here, so that other objects (e.g. plugin composers)
can access the implementation's backing account context.
Hook into the controller's signals for notification of accounts becoming
available so we get AccountContext objects to work with, and hook into
those to get notifications of folders becoming available, and work with
those so plugins get the exact same view of these as the client itself
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.
Don't have a separate blah_changed signal for each property, just have
one and update all props when it is emitted. This happens infrequently
enough that the extra overhead is trivial and simplifies the code base.
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.
Even just logging SQL queries is extremely verbose, and pushes a lot
of logging messages off the end of the buffer. So rework result logging
flag and code to apply to both again.
Re-merge Application.Client's SQL logging command line flags back into
one again.
Rather than scheduling calling a registered log_listener on the default
main loop context, let the listener implementation handle that in
whatever way they want.
Make `suppress_domain`/`unsuppress_domain` return whether they actually
added or removed the suppression. Add `is_suppresed_domain` to allow
determining this at other times.
Blacklisting now prevents records from being created, where as
suppression now simply prevents them from being printed.
This means records are created for all log messages, regardless of
whether they are displayed.
Update API docs for a bunch of methods to make this clear, and to make
the requirements for getting log records in the first place is also
clear.
Update the db's logging to log SQL statements normally, but add a
special case flag to enable logging query results as well, since these
are particularly verbose.
Now that the flags code is gone, move the remaining code from
`src/engine/api/geary-logging.vala` into
`src/engine/util/util-logging.vala`, and remove the former source file.
Now that we have classes logging on sub-domains, and the ability to
suppress specific domains, remove flags and switch over to doing
domain suppression for manipulating debug settings in the client.
