aboutsummaryrefslogtreecommitdiffstats
path: root/e-util/e-alert.h
Commit message (Collapse)AuthorAgeFilesLines
* Pass an EAlertSink to e_alert_sink_submit_alert().Matthew Barnes2010-11-011-2/+4
| | | | | | | 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.
* EAlert: Allow arbitrary actions to be added.Matthew Barnes2010-10-191-10/+4
| | | | | | | | | | | | | | 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.
* Composer: Show cancellable operations and errors inline.Matthew Barnes2010-10-131-4/+12
| | | | | | | | | | | | | | | '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.
* Coding style and whitespace cleanup.Matthew Barnes2010-10-041-1/+1
|
* Messin around with EAlerts.Matthew Barnes2010-09-301-10/+21
| | | | | | | | | | | | | | | | | | | 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.
* EAlert cleanups.Matthew Barnes2010-09-291-61/+47
| | | | Clean up the header, drop some unused cruft.
* Coding style and whitespace cleanup.Matthew Barnes2010-08-291-3/+3
|
* Revert some bad assumptions I made in EPluginUI.Matthew Barnes2010-03-161-1/+1
| | | | | | | | | 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.
* Prevent future bugs like #612792.Matthew Barnes2010-03-151-2/+2
| | | | | | 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.
* Add option to escape EAlert strings.Matthew Barnes2010-02-181-3/+3
| | | | | | 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.
* rename e_alert_get_buttons -> e_alert_peek_buttonsJonathon Jongsma2009-12-091-1/+1
| | | | | Make it obvious that this does not need to be freed like the other things that use get_* (e.g. e_alert_get_title)
* Refactor EAlert to make it a GObjectJonathon Jongsma2009-12-081-11/+61
| | | | | | 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
* Rename EError to EAlert to match general use betterJonathon Jongsma2009-12-011-0/+66
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