EShellBackend now keeps an internal queue of live EActivity objects
passed to it via e_shell_backend_add_activity(). This will eventually
replace "mail_msg_active_table" in mail-mt.c and be used to coordinate
shutdown for all shell backends.
But first I have to eliminate mail_msg_wait().
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.
In GTK+ 2.21.8, the keysym names were renamed from GDK_* to GDK_KEY_*.
I've added backward-compatibility macors to gtk-compat.h, which can be
dumped as soon as we require GTK+ >= 2.22.0.
If we're using GTK+ 2.21.8 (where gtk_dialog_set_has_separator() is
deprecated but the property is still present and defaults to TRUE), we
still need to set the property to FALSE. So instead use g_object_set()
up through GTK+ 2.90.6, after which the property itself is gone.
Unfortunately the default value for this property is TRUE (bzzt, WRONG!)
so we can't just remove the function outright until we require GTK+ 2.22.
It was deprecated in GTK+ 2.21.8.
Given the way the autosave feature was awkwardly bolted on to the
composer, an EExtension seemed like a natural fit. And it helped
clean up some object lifecycle hacks (and bugs).
What we have now is a new module consisting of two EExtensions:
EComposerAutosave extends EMsgComposer and determines when to
kick off an asynchronous autosave operation.
EComposerRegistry extends EShell and offers to restore orphaned
autosave files on startup (which is also asynchronous now).
e-autosave-utils.c holds the actual asynchronous functions and a few
other miscellaneous utility functions.
Source code for the new module lives in /modules/composer-autosave.
e_preferences_window to take factory callbacks and store a reference
to the shell. - This makes start-up substantially faster, particularly
on Atom (eg.).
Remove a number of idle handlers used to create these UIs in the
first instance, cleaning the code.
GIO had a bug for awhile where it would leave behind an empty
temp file with the pattern .goutputstream-XXXXXX if an output
stream operation was cancelled. We've had several reports of
these files in config directories, so remove any we find.
It just doesn't belong in Evolution anymore. We don't support syncing
with more modern devices -- see Conduits or SyncEvolution for that -- so
it does not make sense for older model Palm Pilot PDAs to be the lone
exception.
I have repackaged the Evolution-Data-Server conduit modules to be
provided by gnome-pilot itself in bug #619315. This should provide
eqivalent Palm Pilot syncing functionality; it's just being moved to
gnome-pilot.
This completely severs our dependency on deprecated GNOME 2.x libraries
which were still being dragged in by way of gnome-pilot dependencies.
It was also interfereing with our bundling of libgnomecanvas.
