For messages with a base MIME type of multipart/alternative, we were
hiding text/plain subparts based on the number of alternate subparts.
This assumption of course broke on a message with the following body
structure and a Plain Text Mode preference of "Show HTML if present":
multipart/alternative
text/plain
text/plain
Instead, note when we've actually seen a text/html subpart and use that
to decide whether to hide the text/plain parts.
This will replace the headers API in EMailFormatter. Need a more
permanent place for headers since EMailFormatter is too disposable.
Also add an ESettingsMailPartHeaders class, which binds the new property
to the "show-headers" setting with a suitable mapping function to filter
out disabled header names.
Replaces the "headers" key. Whereas "headers" is an array of XML
blobs, the "show-headers" key is an array of string/boolean pairs.
Also update the appropriate places to get/set the new key.
Mainly to avoid accessing GSettings directly from EMailBrowser.
Also add a "browser-close-on-reply-policy" GSettings key that replaces
"prompt-on-reply-close-browser", the difference being the new key uses
an enum definition compatible with EAutomaticActionPolicy instead of a
free-form string value.
And finally add an ESettingsMailBrowser class to glue things together.
The function now returns TRUE if the ECalClient was actually removed
from the model, or FALSE if the model did not have the ECalClient.
Use this to avoid an unnecessary gnome_calendar_update_query() call
in cal_shell_view_selector_client_removed().
The function now returns TRUE if the ECalClient was actually added
to the model, or FALSE if the model already had the ECalClient.
Use this to avoid an unnecessary gnome_calendar_update_query() call
in cal_shell_view_selector_client_added_cb().
Obtain calendar views asynchronously and concurrently, and update the
task and memo pads synchronously (they don't block as best I can tell).
Get rid of the whole thread-pool message dispatching thing, which I
think I myself wrote years ago (calendar had no async API back then).
Consequently I'm seeing calendar events show up noticably quicker.
As discussed recently on the users mailing list [1], there's a strong
precedent among GTK+ applications for F9 to toggle sidebar visibility.
Examples cited were Nautilus, Evince, Totem, Rhythmbox, File-Roller
and gThumb.
Change the Send/Receive accelerator from F9 to F12, and designate F9
as the accelerator for View->Layout->Show Side Bar.
[1] https://mail.gnome.org/archives/evolution-list/2013-May/msg00194.html
Simplify the EABContactFormatter API as follows:
* Drop all constructor arguments from eab_contact_formatter_new()
since get/set functions exist for all of them.
* Remove eab_contact_formatter_format_contact_async() since
EABContactFormatter does not block.
* Replace eab_contact_formatter_format_contact_sync() with
eab_contact_formatter_format_contact() which drops the CamelStream
and GCancellable arguments and takes a GString as an output buffer.
* Remove the "state" and "style" properties, and always use a white
background when rendering the full contact.
This is particularly important since render_normal() dereferenced
the GtkStyle without checking for NULL, which would crash on mails
with a vCard MIME part when "Show Full vCard" was clicked, because
the "vcard-inline" module never set a GtkStyle.
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.)
In the event of an address book backend abort, EClientCache detects this
and invalidates its cached EClient (if it has one), so a new instance is
created on the next request.
EAddressbookModel is only handed an EClient once, which may become stale
if the backend aborts. And even if the backend is restarted the address
book will remain unresponsive in Evolution.
This commit changes the behavior so that every time an address book is
selected in the side bar, a fresh EClient instance is obtained from the
EClientCache and handed to the EAddressbookModel. If the model already
has that EClient instance, nothing happens. Otherwise the model resets
itself and creates a new EBookClientView.
