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