Passing a random GtkWidget and then searching its ancestors for an
EAlertSink turned out to be not as useful as I thought. Most of the
time we know about and have access to the widget that implements
EAlertSink, so just pass it directly as an EAlertSink.
Trying out a new interface called EAlertSink. The idea is to centralize
how errors are shown to the user. A GtkWindow subclass would implement
the EAlertSink interface, which consists of a single method:
void (*submit_alert) (EAlertSink *alert_sink, EAlert *alert);
The subclass has complete control over what to do with the EAlert,
although I imagine we'll wind up implementing various alert-handling
policies as standalone widgets such as EAlertDialog. I'd like to try
an EAlertInfoBar.
Code that would otherwise display an error dialog itself would instead
pass the EAlert to an appropriate EAlertSink and be done with it.
Nothing is final yet. Still hacking on EAlert trying to find an API
that feels right for these use cases.
In GTK+ 2.21.8, the keysym names were renamed from GDK_* to GDK_KEY_*.
I've added backward-compatibility macors to gtk-compat.h, which can be
dumped as soon as we require GTK+ >= 2.22.0.
By tying the attachment view "editable" action group to comp-editor
"individual" group, these add/remove actions are marked sensitive /
insensitive in sync with the existing "Insert" menu items which are
already in the "individual" group.
Though not introduced with the other symptoms of this bug
(0597b877c5), the descreptency fixed
here is integrally related.
The "view-time-zone" and "view-categories" actions should not have
been grouped with the "individual" action group but rather the "core"
action group, as they should always be available regardless of whether
or not the element being edited is read-only/owned, as they simply
affect visibility of various widgets.
This fixes a bug introduced in 0597b877c5
where these two actions were accidentally grouped with other actions
that should legitimately be in the "individual" group.
This introduces a new action_group called "editable" in the comp-editor
that can be used by other components to assign actions that should be
sensitized separately from the existing "individual" group, such as the
"Alarms" and "Show Time as Busy" event actions.
This fixes a bug introduced in 0597b877c5
where these two actions were accidentally grouped with other actions that
should legitimately be in the "individual" group.
By tying the attachment view "editable" action group to comp-editor
"individual" group, these add/remove actions are marked sensitive /
insensitive in sync with the existing "Insert" menu items which are
already in the "individual" group.
Though not introduced with the other symptoms of this bug
(0597b877c5), the descreptency fixed
here is integrally related.
The "view-time-zone" and "view-categories" actions should not have
been grouped with the "individual" action group but rather the "core"
action group, as they should always be available regardless of whether
or not the element being edited is read-only/owned, as they simply
affect visibility of various widgets.
This fixes a bug introduced in 0597b877c5
where these two actions were accidentally grouped with other actions
that should legitimately be in the "individual" group.
This introduces a new action_group called "editable" in the comp-editor
that can be used by other components to assign actions that should be
sensitized separately from the existing "individual" group, such as the
"Alarms" and "Show Time as Busy" event actions.
This fixes a bug introduced in 0597b877c5
where these two actions were accidentally grouped with other actions that
should legitimately be in the "individual" group.
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.)
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
Milan Crha