An easy way to broadcast application-wide alerts to shell windows.
These alerts will persist in all current and future shell windows
until responded to (either programmatically or by the user).
With unintrusive error dialogs gone, we can cut some unnecessary bits
out of EActivity.
I'm also adding a new enum property called "state", which is one of:
E_ACTIVITY_RUNNING
E_ACTIVITY_WAITING
E_ACTIVITY_CANCELLED
E_ACTIVITY_COMPLETED
The state of an activity must be explicitly changed. In particular,
when the user cancels an activity the state should be set only after
confirming the operation has been cancelled and not when cancellation
is requested (e.g. after receiving a G_IO_ERROR_CANCELLED, not when
the GCancellable emits "cancelled"). EActivityBar and EActivityProxy
widgets have been updated to make this distinction clearer in the UI.
E_ACTIVITY_WAITING will be used when activities have to be queued and
dispatched in sequence, which I haven't written yet.
You can now amend the predefined actions in an EAlert by calling
e_alert_add_action(). Useful for adding actions from an existing
GtkUIManager.
Call e_alert_peek_actions() to obtain a combined list of predefined
and custom actions. These will typically serve as "related" actions
for GtkButtons (cf. gtk_activatable_set_related_action()).
Also, both EShellWindow and EShellView now implement EAlertSink. Use
EShellWindow for application-wide alerts, EShellView for view-specific
alerts.
Listen for "prepare-for-quit" signals from the shell and inhibit
shutdown until all the activities we're tracking are finalized.
Also, add a couple supporting functions:
gboolean e_shell_backend_is_busy (EShellBackend *shell_backend);
void e_shell_backend_cancel_all (EShellBackend *shell_backend);
These will eventually replace mail_msg_active() and mail_cancel_all().
EShellBackend now keeps an internal queue of live EActivity objects
passed to it via e_shell_backend_add_activity(). This will eventually
replace "mail_msg_active_table" in mail-mt.c and be used to coordinate
shutdown for all shell backends.
But first I have to eliminate mail_msg_wait().
EActivity now uses a GCancellable to manage cancellations, instead of
having its own redundant cancellation API. API changes are as follows:
+ e_activity_get_cancellable()
+ e_activity_set_cancellable()
- e_activity_cancel()
- e_activity_is_cancelled()
- e_activity_get_allow_cancel()
- e_activity_set_allow_cancel()
EActivity's "cancelled" signal remains, but only as a repeater for
GCancellable::cancelled signals. It should not be emitted directly.
The presence of a GCancellable implies that cancellation is allowed.
EActivity does not create its own default GCancellable, it has to be
given one.
If a CamelOperation (cast as a GCancellable) is given, EActivity will
configure itself to listen for status updates from the CamelOperation
and propagate the information to its own "primary-text" and "percent"
properties.
These changes allowed me to start cleaning up some of the incredibly
convoluted logic in mail-mt.c -- in particular, mail_operation_status()
is completely gone now. mail-mt.c is still in a transitional state --
much more significant changes coming soon.
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.
Matthew Barnes