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.
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.
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.
Add EmailExtension plugin extenion with context object and
Application.EmailContext implementing it. Check for plugins with
this type in PluginManager and init/deinit their contexts as needed.
Move Capabilities to the api directory and make immutable.
Don't pass around out params to simply increment the revision and use a
field in ClientSession, just use the last capability instance. Ensure
after starting a TLS session capabilities are cleared. Add unit tests
for getting both implicit and explicity capaibilities when initiating
a client session.
Break out the plugin mail store implmeentation out of
NotificationContext into its own EmailStoreFactory class, so it can be
re-used by other plugin context types.
Add Plugin.InfoBar to allow plugins to describe an info bar, add
methods to FolderContext to allow adding and removing them when
folders are displayed and implement them. Add a InfoBarStack to the
MainWindow for displaying folder info bars.
Add new Plugin.FolderExtension plugin extenion interface, context
object and context object implementation. Populate the context object
when plugins implementing the extension are loaded, and destroy it
on unload.
Rename to Components.ProblemReportInfoBar to better describe what it
does, and to fit with the code convention for package and file names.
Derive from Components.InfoBar so we can drop the custom GTK Builder
file for it.
Since libpeas doesn't allow a single plugin instance to have multiple
extensions, define a single libpeas extension as a base class for all
plugins and define extensions as non-libpeas interfaces shared by a
single plugin. Manage loading/unloading these ourselves.
This also defines a new trusted extension interface for plugins that
need access to Geary's internals, new error domain for plugis, and
made the notification context a plugin interface that is implemented by
the application object.
Convert the plugin implementation to use a model where each plugin
has its own context object instances and has limited/no access to the
client's and engine's objects.
Revert merge request GNOME/geary!374 for now since the shared process
model breaks old-style WebProcess message handler IPC.
This can be un-reverted when out JS is ported to the new Messages API
that is landing in WebKitGTK 2.28.
This reverts commit e4a5b85698, reversing
changes made to 66f6525480.
Move into composer namespace and rename to match. Update API for
consistency with style guide. Remove uneeded fields and clarify when
::modified is true. Fix call sites.
Rename source file name and contents to match code convention, add
transation comments, remove extra API in favour of simply exposing the
search entry publically. Extend Hdy.Searchbar so that the width of the
entry grows as needed.
Rename the search folder again to App.SearchFolder, move its id class
into it as an inner class. Remove search folder from the engine so the
application can manage it and it's policy in the future. Also remove
the outbox from the accout's list of local folders, so that code can
be removed altogether.
Move SearchFolder and search EmailIdentifier implementation out of
ImapDb and into its own package. Decouple both from ImapDB, and improve
the implementation, fixing a few inefficiencies. Merge search
FolderProperties into the SearchFoldern implementation as an inner
class.
Merge SearchTerm into ImapDB.SearchQuery as an inner class and move the
outer class's source down a level, since it was the only file left in
the imap-db/search dir.
Rename the class because we need to distinguish between logging sources
and logging state, for cases when the logged object's state may change
between being logged and being displayed.
Rename util souce file to match new name space per source code
convernstion.
Move MainWindow out of the root namespace and add it to Application,
so it can privately share internal state with the Controller. Rename
the source and UI files to match.
Introduce a new standard edit action group "edt" for editing actions
such as copy and undo, separate from the "win" window action group, so
that editing actions can be scoped to specific widgets and overridden
by children. Add new Action namespace with sub-namespaces for the
app, win and edt namespaces and move consts from GearyApplication there.
Update call sites and UI files, use consistent approach to setting up
action groups across all classes that use them.
When an EmailCommand is undone, select the folder, conversation and if
relevant scroll to the email in question so as to provide better
context.
This isn't 100% bulletproof, but is about 80% of the way there. The
remainer requires some major Engine rework to decouple local and remote
actions.
Create new Application.AttachmentManager class and move code for saving
attachments there from both Application.Controller and MainWindow since
aside from needing the latter for dialogs it is independent of both.
Create new Components.AttachmentPane widget for diplaying attachents
for an email in the ConversationViewer.
Update ConversationEmail and ConversationMessage to use these two new
classes directly, rather than implementing save management itself or
requiring the MainWindow to wire up signals on these classes.
