Disabling the mail part of an online account through the Control Center
panel will now remove the CamelService from the EMailSession in addition
to disabling the account/identity/transport ESources, causing it to be
delisted from the account list in Preferences.
Furthermore, hide the Enabled check box for accounts linked to GOA in
Preferences. The collection ESource for these accounts can no longer
be disabled through Evolution; all such account manipulation must be
done through the Control Center panel.
Lastly, display an icon next to accounts linked to GOA in Preferences.
* Might be nice to show the actual provider icon instead of the generic
Online Accounts icon from the Control Center, but need to think about
how best to do that. Don't want a GOA dependency in core Evolution.
Maybe ESourceCollection should grow a GIcon property for the online-
accounts module in the registry service to set?
We're leaking CamelService references when we remove a CamelService
from a CamelSession. I don't yet know where or how.
If we remove a CamelService without finalizing the corresponding ESource,
and then add a new CamelService with the same UID, the ESource will have
a bidirectional "display-name" binding to multiple CamelService instances.
This creates an endless cascade of "notify" signals as soon as any of the
bound "display-name" properties change.
Until I can fix the leaking CamelService references, make the binding
one-way: ESource -> CamelService. This means the ESource's display name
is authoritative, and camel_service_set_display_name() MUST NOT be called
explicitly or else it will become out-of-sync with the ESource.
This is a convenient base class for EMailConfigPages that might need
to run an asynchronous method and display an error message. It adds
activity and alert bars to the bottom of the page, it implements the
EAlertSink interface, and can create new EActivity instances.
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
