| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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")
|
| |
|
|
| |
Convenience function cancels the activity's GCancellable.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
libevolution-utils.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
Planning to write some asynchronous utility functions in e-util that
return EActivity objects.
|
