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.
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().
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.
