| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
This is reverting previous patch for this bug and fixes it with
a different approach. The previous patch had regression, instead
of freezing evolution on quit it crashed it when there was pending
addressbook lookups.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Even send-only accounts should have a backend name of "none".
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Use e_mail_folder_expunge() instead.
|
| |
|
|
| |
To replace mail_expunge_folder().
|
| | |
|
| |
|
|
| |
Use e_mail_reader_refresh_folder() instead.
|
| |
|
|
| |
Replaces e_mail_session_unsubscribe_folder().
|
| |
|
|
| |
compare_folder_name() -> equal_folder_name()
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Remove mail_folder_cache_service_added() and rely instead on
mail_folder_cache_service_enabled()/disabled(). Despite the function
names the folder cache doesn't actually care about enabled status, it
simply maintains a set of CamelStores to monitor. We should refactor
the folder cache API to better reflect that.
EMailAccountStore always immediately follows a "service-added" signal
emission with either a "service-enabled" or "service-disabled" emission,
which will add or remove the service from the folder cache.
|
| |
|
|
|
| |
We have built-in ESources for the 'local' and 'vfolder' mail stores,
and can now track their enabled state as we would any other mail store.
|
| |
|
|
|
|
| |
CamelStoreClass bumps the settings_type to CAMEL_TYPE_STORE_SETTINGS,
which has a filter-inbox property. But we don't want ANY settings in
a CamelNullStore, so revert the settings_type to CAMEL_TYPE_SETTINGS.
|
| |
|
|
|
|
|
|
|
| |
Use e_source_camel_generate_subtype() to register an ESourceCamelNone
class based on the newly-registered "none" CamelProvider.
e_source_camel_register_types() won't pick up the new provider if it was
already called prior to the provider being registered. That might be a
bug... I'm not sure yet. The Camel/ESource integration is kinda messy.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
Always call it immediately after g_simple_async_result_new().
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Replace 8-space indentation with tab characters, and various other
automated cleanups.
|
| |
|
|
| |
allows to store mails in individual INBOX rather than a common one.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
the daemon can now start the vfolder storage without bothering much with the
UI.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Keep this in Evolution's private library directory until the APIs are
fully documented and we begin using libtool versioning on the library.
|
| | |
|
| |
|
|
|
| |
The display name is a user-provided name for the service. We should
be using that in all status messages the refer to the service by name.
|
| |
|
|
|
|
|
|
|
|
|
| |
Evolution kinda sorta supports multiple identities by allowing users
to set up so-called "transport-only" accounts by choosing "None" for
the account type.
Add a CamelStore subclass for those types of accounts so they get
added to EMailAccountStore. It's just a stupid hack to keep another
stupid hack working, but this should sustain us until we can support
multiple identities FOR REAL.
|
| | |
|
|
|
These libraries are bound for E-D-S so they live at the lowest layer of
Evolution for now -- even libeutil can link to them (but please don't).
This is the first step toward moving mail handing to a D-Bus service.
|
