| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
Replaces the 'Dismiss' button. All alerts appearing in an alert bar
should be dismissable (i.e. non-modal). For modal alerts use a dialog.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Warnings are generally meant for transient errors. No need to leave
them up indefinitely. Close them automatically if the user hasn't
responded after a reasonable period of time has elapsed.
|
| | |
|
| | |
|
| |
|
|
|
| |
As of GLib 2.28 all GObject virtual methods, including constructed(),
are safe to chain up to unconditionally. Remove unnecessary checks.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This marks the end of unintrusive error dialogs, which were too
unintrusive. We now show errors directly in the main window using
the EAlert / EAlertSink framework.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Prefer thread-safe G_DEFINE_TYPE and G_DEFINE_INTERFACE macros over
manual GType registration.
This is just a start... lots more to do.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Also, start fixing some Gtk-Doc warnings. There's a lot.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Some error definitions don't specify a title or secondary text. Handle these
situations properly. This was a regression caused by my refactoring. Fixes
bug #604085.
|
| |
|
|
|
| |
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
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=602963
|
|
|
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
|
