| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'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.
|
| |
|
|
|
|
|
| |
Prefer thread-safe G_DEFINE_TYPE and G_DEFINE_INTERFACE macros over
manual GType registration.
This is just a start... lots more to do.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
previously we were storing the EAlert's primary and secondary text in the dialog
object (using g_object_set_data_full). Since EAlertDialog encapsulates an
EAlert and we have access to the underlying EAlert object, we can just use the
EAlert API to get the primary and secondary text rather than storing duplicates
copies of it in the dialog.
|
|
|
Planning to write some asynchronous utility functions in e-util that
return EActivity objects.
|
