e_mail_reader_get_folder() does not return a new CamelFolder reference,
yet mail_to_event() was acting as though it does. This caused a crash
after the function ran and Evolution tried to use the folder again.
Truth be told, e_mail_reader_get_folder() really *should* return a new
reference to ensure the CamelFolder is not finalized while it's in use.
But we would need to rename the function to e_mail_reader_ref_folder()
to reflect the change in semantics, and I suspect the function is used
in a great many places.
em_utils_print_messages_to_file() was doing so asynchronously, but
unfortunately drag-n-drop is a synchronous protocol. So by the time
the asynchronous print operation completed, the URI list pointing to
the temporary PDF files had already been passed to the file manager.
The only reason the files were created at all was because we test the
generated file name with open(...O_CREAT...) before starting the print
operation, and I'm not convinced that test is even necessary.
This adds a GAsyncReadyCallback and a closure to e_mail_printer_print(),
and trades the "done" signal for e_mail_printer_print_finish() so that
EMailPrinter is a little more reentrant.
We used to do this before WebKit and it looked better.
Also fix up the header section for right-to-left locales:
put the collapse button on the right, and images on the left.
Obtain an EClient for contact photo lookup asynchronously. If an
instance needs to be created, it's more likely created in a thread
with a main loop so signal emissions can work.
Unless the button to choose a calendar was clicked, because
the calendar path is not filled, thus the server claims
"HTTP 405 error", which means an OPTIONS request cannot be done
on the path, which was just root of www.google.com, instead
of a calendar path. (This was reported as part of bug #659522.)
