Append the build profile to Geary's data directories when not running
a release build (or under Flatpak) so that e.g. development builds use
different config, cache and data directories.
This allows us to perform things like database schema updates with
relative abandon, since if we ask people to test development builds
with schema updates, they can always safely go back to their release
builds again.
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
Now that the `:focus-within` pseudoclass is supported, use this rather
than some custom JS to update custom HTML classes. This also prevents
spurious mutation events from firing.
Move selection changed event listener into JS so it doesn't have to
cross the JS/native boundary twice.
Move sending remote load blocked from JS to the extension since we can
do that directly now and again so the JS/native boundary doesn't need
to be double-crossed again.
Stop needlessly wrapping object members and array elements in
variant variants.
Don't wrap object values in variants since the code is already using
vardicts for these. Return a variant array if a JS array contains values
of all the same type and don't wrap these in variants, else return
a tuple, which don't need to be wrapped either.
Define a vala-backed JS class in the extension and make that available
to pages when they are registered. Add some helper JS to PageState for
defining message sending functions. Listen for these in
Components.WebView and dispatch to the registered callback for it.
Update web extension to check for errors when invoking page state
methods and pass a message back if found. Check for this, decode and
throw a vala error in the WebView if found.
Use WebKitGTK UserMessage objects for invoking JS methods rather than
serialising to JS strings and running those. This is possibly slightly
less efficient, but removes the onus on serialising to and parsing from
JS and once switched over from message handlers to UserMessage objects
will be using a single uniform IPC interface for both.
This moves the actions from the headerbar to the action bar at the
bottom of the conversations list when multiple conversations are
selected. This changes is needed so that the user can still interact
with the conversations when folded.
This also hides the actions from the Headerbar and action bar when
no conversation is selected.
This creates a new object that contain the 4 groups of actions that used
to be in the conversation-viewer headerbar.
This allows the widgets to be moved to differen locations, e.g. to an
action bar that will be added in a later commit.
