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.
Restore the update() method in ECanvasBackground. Without a redraw
request the draw() method is never called. For some reason this isn't
noticeable on gtk+-3.0 -- ETable and ETree backgrounds are still white
-- but on gtk+-2.0 the backgrounds are grey.
Way easier than to try to get the coordinates right.
Includes refactoring to introduce e_map_world_to_render_surface() that
computes coordinates on the background surface to make this stuff
easier.
The in_view() check is broken because it doesn't repaint points that are
1px outside the window. The point take 2 extra pixels in every direction
after all. And gtk_widget_queue_draw_area() will automatically discard
out-of-range rects anyway.
Previously the function returned the distance to the nearest item. Now
it only returns an item that is hit. This slightly changes semantics
(button events are no longer dispatched to the nearest item, but only to
the item actually clicked on), but makes the code way simpler and
actually does what one would expect.
With unintrusive error dialogs gone, we can cut some unnecessary bits
out of EActivity.
I'm also adding a new enum property called "state", which is one of:
E_ACTIVITY_RUNNING
E_ACTIVITY_WAITING
E_ACTIVITY_CANCELLED
E_ACTIVITY_COMPLETED
The state of an activity must be explicitly changed. In particular,
when the user cancels an activity the state should be set only after
confirming the operation has been cancelled and not when cancellation
is requested (e.g. after receiving a G_IO_ERROR_CANCELLED, not when
the GCancellable emits "cancelled"). EActivityBar and EActivityProxy
widgets have been updated to make this distinction clearer in the UI.
E_ACTIVITY_WAITING will be used when activities have to be queued and
dispatched in sequence, which I haven't written yet.
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.
