aboutsummaryrefslogtreecommitdiffstats
path: root/e-util/e-activity.h
Commit message (Collapse)AuthorAgeFilesLines
* Add e_activity_get_last_known_text().Matthew Barnes2013-07-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Evolution is still occasionally getting stuck on shutdown, and although the evolution-shell log domain shows debug messages for activities that are preventing shutdown, they frequently look like this: (evolution:13534): evolution-shell-DEBUG: 5 active 'mail' activities: (evolution:13534): evolution-shell-DEBUG: * (no description) (evolution:13534): evolution-shell-DEBUG: * (no description) (evolution:13534): evolution-shell-DEBUG: * (no description) (evolution:13534): evolution-shell-DEBUG: * (no description) (evolution:13534): evolution-shell-DEBUG: * (no description) I think the lack of descriptions is from CamelOperations popping all their pushed messages, which is correct behavior but doesn't help us debug the problem. e_activity_get_last_known_text() returns the most recent _non-empty_ text value set on the EActivity. So our debug message can fall back to that if the EActivity has no description at shutdown: (evolution:13534): evolution-shell-DEBUG: * (was "blah, blah, blah")
* Add e_activity_cancel().Matthew Barnes2013-04-251-0/+1
| | | | Convenience function cancels the activity's GCancellable.
* Finish adding symbols to libeutil API docs.Matthew Barnes2012-12-151-1/+1
|
* Consolidate base utility libraries into libeutil.Matthew Barnes2012-12-131-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 references from other part of the code to ↵Srinivasa Ragavan2012-03-031-1/+1
| | | | libevolution-utils.
* Add e_activity_handle_cancellation().Matthew Barnes2011-05-121-0/+2
| | | | | | | | Convenience function for use in GAsyncReadyCallback functions. This acknowledges the cancellation, so that the activity's description changes from "(cancelling)" to "(cancelled)" and the description appears crossed out in the UI for a moment before disappearing.
* EActivity: Add an "alert-sink" property.Matthew Barnes2010-11-011-2/+4
| | | | | | | This is just for convenience, EActivity does not use this property. Especially useful in async function callbacks when the operation failed and now you have to do something useful with the GError.
* Simplify EActivity.Matthew Barnes2010-10-231-16/+8
| | | | | | | | | | | | | | | | | | | | | | 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.
* Add a GCancellable to EActivity.Matthew Barnes2010-09-191-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EActivity now uses a GCancellable to manage cancellations, instead of having its own redundant cancellation API. API changes are as follows: + e_activity_get_cancellable() + e_activity_set_cancellable() - e_activity_cancel() - e_activity_is_cancelled() - e_activity_get_allow_cancel() - e_activity_set_allow_cancel() EActivity's "cancelled" signal remains, but only as a repeater for GCancellable::cancelled signals. It should not be emitted directly. The presence of a GCancellable implies that cancellation is allowed. EActivity does not create its own default GCancellable, it has to be given one. If a CamelOperation (cast as a GCancellable) is given, EActivity will configure itself to listen for status updates from the CamelOperation and propagate the information to its own "primary-text" and "percent" properties. These changes allowed me to start cleaning up some of the incredibly convoluted logic in mail-mt.c -- in particular, mail_operation_status() is completely gone now. mail-mt.c is still in a transitional state -- much more significant changes coming soon.
* Move EActivity and subclasses to e-util.Matthew Barnes2009-11-081-0/+98
Planning to write some asynchronous utility functions in e-util that return EActivity objects.