| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Yikes, that would be bad...
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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.
|
| |
|
|
|
| |
Stop searching address books on the first error but don't indicate
failure if we've managed to accumulate contacts prior to the error.
|
| | |
|
|
|
Caches contact photos by email address.
Replaces the disastrous implementation in e-mail-utils.c.
|
