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()
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.
Mimicing Colin's commit fb9b02e for E-D-S.
We can't do (cd $(srcdir); ...) and inside reference $(top_srcdir)
because that variable uses a *relative* path. Thus we copy the
approach from gnome-shell of explicitly using addprefix to append
the source directory.
Calling webkit_get_web_plugin_database() somehow ends up calling
g_bus_get_sync(), which in turn makes gtkdoc-scangobj hang forever.
Call it instead as a GOnce callback during instance initialization,
which avoids the hang since gtkdoc-scangobj only peeks at classes.
Loads a UI definition into a GtkUIManager from Evolution's UI directory.
We actually had this function for a brief period during the 2.29 series,
before Express Mode was a thing. I'm reviving the function to take over
for EUIManager.
Use g_simple_async_result_complete_in_idle() so the queued results
complete in the correct main loop context. Otherwise we get runtime
warnings:
"g_simple_async_result_complete() called from wrong context!"
These aren't as efficient as possible, but are as clear as possible.
New functions:
e_weekday_add_days()
e_weekday_subtract_days()
e_weekday_get_days_between()
This enum type is intentionally compatible with GDateWeekday.
It exists only because GLib does not provide a GEnumClass for
GDateWeekday. If that ever changes, this enum can go away.
Matthew Barnes