These functions now return new references:
camel_session_add_service()
camel_session_list_services()
These functions have been renamed and also return new references:
camel_session_get_service() -> camel_session_ref_service()
camel_session_get_service_by_url() -> camel_session_ref_service_by_url()
The evolution-settings capplet was originally designed for Anjal, it was
used in MeeGo as part of the Express Mode effort, but doesn't really fit
in GNOME 3 nowadays (nor did it really fit in GNOME 2, in my opinion).
This is pretty clearly dead weight at this point. The MeeGo developers
have disappeared, and the remaining Evolution developers are not and do
not intend to maintain it. Plus it doesn't even build currently.
This reverses the removal of the "Mark messages as read" preference in
commit e7247d6d60.
I apparently misjudged the popularity of this preference, as there's
been a surprising amout of backlash and confusion as to its removal on
the mailing list, IRC channel, and various distro-support forums.
So, "mea culpa" for removing that one. Haven't heard a peep about the
other removed preferences, however, so they will stay gone.
The story on this is a question [1] was recently posed to the mailing
list about what's the different between "Recent Messages" and "Last 5
Days' Messages" as listed in the Show: combo box, and even I could not
answer before looking up the query expression for "Recent Messages" in
the source code (messages received in the past 24 hours, it turns out).
I can't defend why we need both options, and "Last 5 Days' Messages"
is less ambiguous and overlaps the results for "Recent Messages", so
"Last 5 Days' Messages" seems sufficient to me. There are numerous
ways to re-create the "Recent Messages" query if it's still desired:
saved search, search folder, or just sort messages by date received.
[1] https://mail.gnome.org/archives/evolution-list/2012-July/msg00044.html
em_folder_tree_get_selected_folder() currently blocks, and I'm about to
remove the function. But there's a couple places where we just need to
block for now, else it would require a significant rewrite. So execute
the em_folder_tree_get_selected_folder() logic manually in those places.
This will force Evolution to reconnect to the service using the current
settings. However this is not a complete solution. If the new settings
now point to a completely different mail account, we leave behind cached
messages and database tables from the previous account such that you end
up with some weird hybrid of the previous account and current account.
I guess for now the answer is "don't do that", but we should try to
handle that more gracefully in the future -- more for architectural
correctness than it being a common real world use case.
The new formatter was ignoring selected headers, always displaying
only From, To, Subject and Date (default headers).
Handling of the currently displayed headers has been moved to
EMailConfigFormatHTML extension, because it is related to
configuration of EMailFormatter, rather then EMailReader.
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.
The evolution-settings capplet was originally designed for Anjal, it was
used in MeeGo as part of the Express Mode effort, but doesn't really fit
in GNOME 3 nowadays (nor did it really fit in GNOME 2, in my opinion).
Add a --with-capplet configure switch defaulting to 'no'. The capplet
will eventually be removed unless I see someone actively maintaining it.
em_utils_connect_service_sync() and em_utils_disconnect_service_sync()
are no longer needed. CamelService itself now effectively does what
these functions were doing.
Drop the "libevolution" prefix so it's not so verbose and also
consistent with upcoming evolution-data-server module libraries.
libevolution-module-foo.so --> module-foo.so
