We can't require the use of EUIManager everywhere because we don't
control all the UI manager instances -- the most compelling example
being the composer, whose UI manager comes from GtkhtmlEditor.
Instead, EPluginUI will check the instance type and pick an appropriate
"load_from_string" function.
Replace the EVO_EXPRESS environment variable with an --express command
line option. (Note, this adds a new translatable string for --help.)
Add an EUIManager class with an "express-mode" property and custom load
functions that use our new "express" preprocessor. This replaces the UI
manager functions in e-utils.c.
(Also going to see if I can get GTK+ to add an "add_ui_from_string"
method to GtkUIManagerClass that we can override. Then we could just
call gtk_ui_manager_add_ui_from_string() and the preprocessor would
automatically do its thing and chain up.)
Add an "express-mode" read-only GObject property to EShell.
Add e_shell_configure_ui_manager() to e-shell-utils.c. For now this
just creates a one-way property binding:
EShell:express-mode -> EUIManager:express-mode
Call this immediately after e_ui_manager_new(). (EUIManager can't do
this itself because it lives too low in the dependency hierarchy and
doesn't know about EShell.)
The "deactivate" handler for EAttachmentButton's popup menu was never
disconnected, and I suspect it may be getting invoked after the button
has been finalized.
GtkAssistant's initial reference is floating, so if command-line import
fails to find a suitable importer, sink the reference before finalizing
the GtkAssistant.
Avoid listing calendar and directory targets explicitly, so that
e-selection.c contains the one and only master list. Still need
to figure out how to centralize "text/x-source-vcard".
Add "copy-target-list" and "paste-target-list" to the ESelectable
interface. These are underutilized for the moment, but will eventually
be used to help integrate drag-and-drop support into ESelectable.
Add cut and paste support to EWebView, along with a new "editable"
property and new clipboard signals "copy-clipboard", "cut-clipboard" and
"paste-clipboard".
In EFocusTracker, listen for "owner-changed" signals from the default
clipboard as another trigger to update actions, particularly the Paste
action. (Unfortunately this doesn't work for EWebView since GtkHtml
implements its own clipboard.)
In EMsgComposer, convert GtkhtmlEditor's clipboard methods to empty
stubs, since EFocusTracker will now trigger EWebView's clipboard
actions. Also, intercept EWebView::paste-clipboard signals and improve
the interaction between the HTML editor and the attachment bar based on
use cases in bug #603715.
EFocusTracker tracks the input focus within a window and helps keep
the sensitivity of "selectable" actions in the main menu up-to-date.
Selectable actions include Cut, Copy, Paste, Select All and Delete.
EFocusTracker has built-in support for widgets that implement the
GtkEditable interface such as GtkEntry and GtkTextView. It also
supports custom widgets that implement the ESelectable interface,
which is a subset of GtkEditable and can apply to anything that
displays selectable content (esp. tree views and ETables).
This commit integrates EFocusTracker with EShellWindow, CompEditor,
EMsgComposer, and ESignatureManager.
It also bumps the GtkHTML requirement to 2.29.5 to utilize the new
GtkhtmlEditor:html constructor property.
The changes are mainly including the e-alert-header.h header instead of just
e-alert.h. This allows us to include e-alert.h in non-UI situations when
necessary.
The EError mechanism is used both for error dialogs as well as basic alerts or
user prompts, so we should give it a more general name which matches this use.
This patch also cleans up a few includes of e-alert.h (formerly e-error.h) that
were not actually being used.
https://bugzilla.gnome.org/show_bug.cgi?id=602963
Don't unref the GAsyncResult in finish functions. Do it after calling
g_simple_async_result_complete(). This allows the GAsyncReadyCallback
to be optional, and we'll still clean up resources properly.
Also, don't call g_simple_async_result_complete_in_idle() unless we're
completing an operation from a separate thread, which we're not in any
of the current cases.
Matthew Barnes