| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'Send' and 'Save Draft' are now asynchronous and run outside of
Evolution's MailMsg infrastructure.
Add an EActivityBar to the composer window so these asynchronous
operations can be tracked and cancelled even in the absense of a main
window. Also add an EAlertBar to the composer window so error messages
can be shown directly in the window.
Instead of calling e_alert_dialog_run_for_args(), call e_alert_submit()
and pass the EMsgComposer as the widget argument. The EMsgComposer will
decide whether to show an EAlertDialog or use the EAlertBar, depending
on the GtkMessageType of the alert.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Clean up the header, drop some unused cruft.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Add G_GNUC_NULL_TERMINATED to EAlert functions with variable-length
parameter lists and drop the unnecessary "arg0" parameter so the
function attribute works correctly.
|
| |
|
|
|
|
| |
EAlertDialog wants the primary and secondary strings escaped for use in
markup text, EActivityProxy does not use markup. So make it an explicit
part of the EAlert API.
|
| |
|
|
|
| |
Make it obvious that this does not need to be freed like the other things that
use get_* (e.g. e_alert_get_title)
|
| |
|
|
|
|
| |
This encapsulates things a bit better and will be useful in the future since it
will probably need to be a GObject if we want to communicate EAlerts between the
front- and back-ends
|
|
|
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
|
