Add a load_string() method to EWebView. Have EMailDisplay override
load_string() and check that the formatter is not busy before loading
the string. Have EMailReader call e_web_view_load_string() directly
on the EMailDisplay instance, and eliminate update_webview_content().
Make EWebView extensible and register an extension to automatically
bind every EWebView instance to the appropriate EShellSettings.
Conflicts:
widgets/misc/e-web-view.c
Make ECalendarItem, ECalendarView, ECalModel, EDateEdit, EMeetingStore,
and EMeetingTimeSelector extensible and register extensions to
automatically bind every instance to the appropriate EShellSettings.
Conflicts:
calendar/gui/gnome-cal.c
modules/calendar/e-cal-shell-content.c
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.)
To avoid another case like bug #587014, add GSignalAccumulator functions
to all ETable and ETree signals that return a flag to indicate the signal
has been handled.
See commit e9dc381d3a for an example of
the kind of problems not having a GSignalAccumulator can cause.
Signals changed:
ETree::click
ETree::right-click
ETree::white-space-event
ETable::click
ETable::key-press
ETable::right-click
ETable::start-drag
ETable::white-space-event
ETableItem::click
ETableItem::right-click
ETableItem::start-drag
ETableGroup::click
ETableGroup::key-press
ETableGroup::right-click
ETableGroup::start-drag
Neither ETree::key-press nor ETableItem::key-press signal definitions
specify a GSignalAccumulator that terminates the signal emission when
a handler returns TRUE, and Evolution 2.29 connects multiple handlers
to ETree::key-press.
When the space key is pressed, the first handler implements the magic
space bar behavior and returns TRUE, which should terminate signal
emission but doesn't because there's no accumulator function on the
signal. So the second handler runs and checks for other keys besides
space. It returns FALSE since it didn't handle the key press.
End result: emission site gets back FALSE (from the second handler) as
the return value, so it thinks the key press was not handled at all and
invokes the fallback handler -- e_selection_model_toggle_single_row() --
which -unselects- the newly selected row, making it appear the next
unread message was never selected.
Several other ETable-related signals that return "handled" flags also
lack GSignalAccumulator functions. I've made a note to myself to fix
those as well.
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.
