Apparently MessageList eats the CamelFolderChangeInfo it gets from the
CamelFolder::changed signal. My confidence in this patch is shaky. The
logic is pretty messy and we could easily be leaking memory here. Could
use some hot valgrind action.
As of commit 7fa0dd78305677d14839a480fc379ebba3a6d55c, all CamelFolder
and CamelStore signals are emitted from idle callbacks. That means we
don't have to propagate events to the main loop thread anymore, which
eliminates all remaining uses of MailAsyncEvent.
Rewrite the last usage of it in itip-formatter.c to use EAttachments
instead. This also allowed me to kill mail_save_part() in mail-ops.c.
I may need to reevaluate the EAttachment API at some point for all these
fringe EAttachment uses we're accumulating. Having to asynchronously
"load" an EAttachment whose content is already in memory kinda sucks.
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.
All this time I never realized the subject-thread plugin was nothing
more than a stupid checkbox. The actual thread-by-subject code lives
in the core mail library.
Move alert checkboxes to a new "Confirmations" tab and reword the
options. Also, split reply and forward-related options into a new
"Replies and Forwards" section.
Remove some options from Mail Preferences that aren't worth the screen
real estate they take up. For now, the corresponding GConf keys still
remain and are honored by Evolution. These same options were already
removed for Express mode.
Options removed are:
[ ] Mark messages as read after XXX seconds
[ ] Do not display messages when text size exceeds XXX KB
[ ] Shrink To / Cc / Bcc headers to XXX addresses
[ ] Enable Magic Spacebar
[ ] Enable Search Folders
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.
