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.
Fix regression from commit 99a875ed which has broken displaying
of suppressed HTML parts as attachments when the HTML part is embedded
in a multipart/* container.
Commit 6905e9ed885cd1d5be26106d64831a6d35c36bd9 permanently enabled the
on-disk cache in EDS for Google Contacts address books, so the option is now
redundant.
For consistency with the Preferences window. We assume the display
names are server-assigned and not user-assigned, at least not assigned
through Evolution.
ECalSourceConfig drags in no additional dependencies, and although we do
publish a libevolution-calendar.so, this keeps all the ESource config UI
in one place so it can more easily be moved to Evolution-Data-Server.
EBookSourceConfig drags in no additional dependencies, and allows us to
delay publishing a libevolution-addressbook.so since 3rd party packages
will need to subclass EBookSourceConfig.
The address book source code will need to be flattened into a single
library before we could publish a libevolution-addressbook.so anyway.
That would be a good thing to do regardless -- Evolution has way too
many internal libraries -- but it's out of scope at the moment.
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.
