| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
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().
|
| |
|
| |
|
|
|
|
|
| |
the daemon can now start the vfolder storage without bothering much with the
UI.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|