This commit does a number of things which I could not subdivide into
smaller commits.
* Converts ETreeModel to an interface, implemented by MessageList.
* Drops ETreeMemory and ETreeMemoryCallbacks, which were ETreeModel
subclasses. Their functionality is subsumed by MessageList.
* MessageList drops its public ETreeModel pointer, since MessageList
now implements ETreeModel as an interface.
* Adds message_list_set_expanded_default(), which takes over for
e_tree_memory_set_expanded_default().
Also add a placeholder ESettingsMessageList extension. Going to clean
out some of the direct GSettings usage in MessageList by adding GObject
properties and binding them to GSettings keys from the extension.
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.
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.
EShellSettings predates GSettings and is no longer necessary.
GSettings allows binding GObject properties to GSettings keys,
with optional mapping functions. That fulfills the purpose of
EShellSettings.
EShellSettings predates GSettings and is no longer necessary.
GSettings allows binding GObject properties to GSettings keys,
with optional mapping functions. That fulfills the purpose of
EShellSettings.
This class is different from the others in this module. Its purpose
is to transfer values from deprecated GSettings keys to the preferred
keys on startup, and keep them synchronized at all times for backward
compatibility.
Initial deprecated keys being handled are:
"week-start-day" (org.gnome.evolution.calendar)
"working-days" (org.gnome.evolution.calendar)
Listens for "client-created" signals from its EClientCache. If the
newly-created client is an ECalClient, automatically configure its
default timezone from EShellSettings.
GTK+ uses (G_PRIORITY_HIGH_IDLE + 20) for redrawing operations, which is
actually a slightly lower priority than G_PRIORITY_HIGH_IDLE. Therefore
for our purpose, G_PRIORITY_HIGH_IDLE is sufficient.
This reverts commit 2b507716b2.
The commit contains not a single comment as to why these custom priority
values are being used. The rationale needs to be documented in the code,
either at each call point or preferrably at a centralized priority value
definition.
Collect all the "config" extensions from the "addressbook", "calendar",
and "mail" modules into one place. These extensions typically just bind
GObject properties of extensible classes to app-specific GSettings keys.
