The ESourceRegistry can still be obtained from the EClientCache:
client_cache = e_composer_header_table_ref_client_cache (table);
registry = e_client_cache_ref_registry (client_cache);
...
g_object_unref (client_cache);
g_object_unref (registry);
Added functions:
e_composer_header_table_ref_client_cache()
Removed functions:
e_composer_header_table_get_registry()
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 removes all traces of Express Mode from all but the contact editor
and calendar appointment editor. Need to evaluate the remaining cases
individually.
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.
Using gtk_box_new() instead of gtk_vbox_new() changes the way child
widgets are packed by default via gtk_container_add(). gtk_vbox_new()
expands them by default, gtk_box_new() does not, and the preview pane
was being packed with gtk_container_add().
Packing widgets into a GtkBox with gtk_container_add() is usually the
wrong way. Use gtk_box_pack_start() instead, with expand=TRUE.
g_hash_table_add(table, key) uses less memory than
g_hash_table_insert(table, key, GINT_TO_POINTER (1)).
Also use g_hash_table_contains() when testing for membership.
Move the supporting widgets for the contact maps feature alongside
EABContactDisplay. Removing them from libeutil helps isolate our usage
of libchamplain so it's not imposed on the entire application, and even
3rd party software. That libchamplain is an optional dependency only
further complicates the matter.
Ideally I'd like to somehow isolate this feature in an extension module,
but we currently lack sufficient hooks for such an extension. So this
arrangement will have to suffice for now.
Evolution consists of entirely too many small utility libraries, which
increases linking and loading time, places a burden on higher layers of
the application (e.g. modules) which has to remember to link to all the
small in-tree utility libraries, and makes it difficult to generate API
documentation for these utility libraries in one Gtk-Doc module.
Merge the following utility libraries under the umbrella of libeutil,
and enforce a single-include policy on libeutil so we can reorganize
the files as desired without disrupting its pseudo-public API.
libemail-utils/libemail-utils.la
libevolution-utils/libevolution-utils.la
filter/libfilter.la
widgets/e-timezone-dialog/libetimezonedialog.la
widgets/menus/libmenus.la
widgets/misc/libemiscwidgets.la
widgets/table/libetable.la
widgets/text/libetext.la
This also merges libedataserverui from the Evolution-Data-Server module,
since Evolution is its only consumer nowadays, and I'd like to make some
improvements to those APIs without concern for backward-compatibility.
And finally, start a Gtk-Doc module for libeutil. It's going to be a
project just getting all the symbols _listed_ much less _documented_.
But the skeletal structure is in place and I'm off to a good start.
Collect EMailParts in a GQueue provided to the EMailParserExtension,
and change the return type of parse() to gboolean to indicate whether
the given CamelMimePart was handled (even if no parts were added to
the output GQueue).
This avoids the awkward corner case of a parser extension returning a
linked list node with a NULL data member to indicate the CamelMimePart
was handled but no EMailParts produced, and then having to watch out
for that NULL data member corner case throughout the application.
Also, remove the GCancellable parameter from e_mail_parser_error() and
e_mail_parser_wrap_as_attachment() since neither function blocks.
Exposing data members in the public struct is unwise, especially when
EMailPartList is used from multiple threads. Instead keep the members
private and provide a set of thread-safe functions to manipulate them.
This came about from a mailing list thread entitled:
Sending photos from digKam: "Skipping suspicious attachment"
Apparently KDE still uses dot-folders quite heavily, despite having
helped draft the XDG Base Directory Specification.
All mail-parsing and formatting code has been moved to em-format.
Parsing is handeled by EMailParser class, formatting by EMailFormatter.
Both classes have registry which hold extensions - simple classes
that do actual parsing and formatting. Each supported mime-type
has it's own parser and formatter extension class.
Our hidden file/directory blacklist went a little too far. Evolution
was blacklisting its own temporary files. This changes the blacklist
function to trust the user's own XDG Base Directories.
