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.
This seems to have started with the gravatar module. SoupRequest is
apparently quite eager to cancel HTTP requests -- so much so that we
need to slow it down within EPhotoCache, so we don't wind up calling
g_cancellable_disconnect() during a GCancellable signal emission.
Remove this status message nonsense that I came up with during the
kill-bonoto rewrite. Instead submit a real EActivity to the shell
backend. Mismanagement of the status message seems to be blocking
application shut down in some cases.
Remove this status message nonsense that I came up with during the
kill-bonobo rewrite. Instead submit a real EActivity to the shell
backend. Mismanagement of the status message sesms to be blocking
application shut down in some cases.
Remove this status message nonsense that I came up with during the
kill-bonobo rewrite. Instead submit a real EActivity to the shell
backend. Mismanagement of the status message seems to be blocking
application shut down in some cases.
Reimplement EPhotoCache to delegate the actual photo fetching to
EPhotoSources. When a photo is requested for a given email address,
all available EPhotoSources are dispatched concurrently and a photo
input stream is selected from the result set.
This also utilizes EDataCapture, which is affixed to the returned
GInputStream to capture and cache photo data for an email address.
New functions:
e_photo_cache_add_photo_source()
e_photo_cache_list_photo_sources()
e_photo_cache_remove_photo_source()
e_photo_cache_add_photo()
Renamed functions:
e_photo_cache_remove() --> e_photo_cache_remove_photo()
This encapsulates the EContactPhoto look up feature that was previously
built into EPhotoCache. It's now implemented as an EPhotoSource -- one
per address book. One advantage of this implementation is that address
books are now queried concurrently rather than serially.
EPhotoCacheContactLoader is an EPhotoCache extension that takes care of
adding and removing EPhotoSources for available address books.
EPhotoSource is an interface used to extend the functionality of
EPhotoCache. You can add an object implementing EPhotoSource to an
EPhotoCache with e_photo_cache_add_photo_source() and remove it with
e_photo_cache_remove_photo_source(). When EPhotoCache needs a photo
for an email address, it will invoke e_photo_source_get_photo() on all
available EPhotoSource objects simultaneously and select one photo.
EDataCapture is a GConverter that captures data until the end of the
input data is seen, then emits a "finished" signal with the captured
data in a GBytes instance.
When used with GConverterInputStream or GConverterOutputStream, an
EDataCapture can discreetly capture stream content for the purpose
of caching.
It could happen that header text color had been picked white one time,
but the other time black as expected (for me usually when I started
Evolution in Calendar and moved to Mail view, the header text color
was white, while when starting in Mail view it was black). The change
to use GtkStyleContext is there only as a cleanup from deprecated
GtkStyle, and to make things easier too, because both GtkStyle
and the GtkStyleContext had set white color for some reason.
This was added as part of bug 360184 but no justification was given
for the "local-only" part. My Spidey sense tells me it was a hack-
around for the old implementation's tendency to freeze the UI while
searching for a photograph. So the "local-only" option really just
meant "don't freeze the UI for very long, please".
The new EPhotoCache-based implementation in 3.8 NEVER freezes the UI,
so the "local-only" option is no longer needed. If a remote address
book is slow or unresponsive we simply cancel the async photo lookup
when the user moves on to another email.
