aboutsummaryrefslogtreecommitdiffstats
path: root/e-util/e-alert-sink.c
Commit message (Collapse)AuthorAgeFilesLines
* Replace 'interface' with 'iface' in the codeTarnyko2014-02-261-6/+6
| | | | | | Win32 headers have a #define for 'interface', which breaks the build when this word is used in the code, thus replace it to 'iface', the same way as GLib or GTK+ code use to have it. (See bug #722068.)
* Bug 721545 - License text contains obsolete FSF postal addressMatthew Barnes2014-01-081-10/+9
|
* Consolidate base utility libraries into libeutil.Matthew Barnes2012-12-131-0/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Evolution consists of entirely too many small utility libraries, which increases linking and loading time, places a burden on higher layers of the application (e.g. modules) which has to remember to link to all the small in-tree utility libraries, and makes it difficult to generate API documentation for these utility libraries in one Gtk-Doc module. Merge the following utility libraries under the umbrella of libeutil, and enforce a single-include policy on libeutil so we can reorganize the files as desired without disrupting its pseudo-public API. libemail-utils/libemail-utils.la libevolution-utils/libevolution-utils.la filter/libfilter.la widgets/e-timezone-dialog/libetimezonedialog.la widgets/menus/libmenus.la widgets/misc/libemiscwidgets.la widgets/table/libetable.la widgets/text/libetext.la This also merges libedataserverui from the Evolution-Data-Server module, since Evolution is its only consumer nowadays, and I'd like to make some improvements to those APIs without concern for backward-compatibility. And finally, start a Gtk-Doc module for libeutil. It's going to be a project just getting all the symbols _listed_ much less _documented_. But the skeletal structure is in place and I'm off to a good start.
* Move EAlert* and e-xml-utils to libevolution-utils.Srinivasa Ragavan2012-03-031-93/+0
|
* Bug #646109 - Fix use of include <config.h> to make sure translations workMilan Crha2011-05-271-0/+4
|
* Pass an EAlertSink to e_alert_sink_submit_alert().Matthew Barnes2010-11-011-18/+7
| | | | | | | 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-14/+22
| | | | | | | | | | | | | | 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.
* Messin around with EAlerts.Matthew Barnes2010-09-301-0/+92
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.