Evolution consists of entirely too many small utility libraries, which
increases linking and loading time, places a burden on higher layers of
the application (e.g. modules) which has to remember to link to all the
small in-tree utility libraries, and makes it difficult to generate API
documentation for these utility libraries in one Gtk-Doc module.
Merge the following utility libraries under the umbrella of libeutil,
and enforce a single-include policy on libeutil so we can reorganize
the files as desired without disrupting its pseudo-public API.
libemail-utils/libemail-utils.la
libevolution-utils/libevolution-utils.la
filter/libfilter.la
widgets/e-timezone-dialog/libetimezonedialog.la
widgets/menus/libmenus.la
widgets/misc/libemiscwidgets.la
widgets/table/libetable.la
widgets/text/libetext.la
This also merges libedataserverui from the Evolution-Data-Server module,
since Evolution is its only consumer nowadays, and I'd like to make some
improvements to those APIs without concern for backward-compatibility.
And finally, start a Gtk-Doc module for libeutil. It's going to be a
project just getting all the symbols _listed_ much less _documented_.
But the skeletal structure is in place and I'm off to a good start.
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.
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.
More mail API churn... reversing some previous API decisions.
I've made some key API changes to EMailSession on the account-mgmt
branch which should allow for this, and will hopefully also benefit
the "email-factory" branch.
EMailBackend barely needs to exist anymore, except as the owner of
EMailSession.
For several low-level functions, we replace its EMailBackend parameter
with EMailSession and EAlertSink parameters; the latter so it can still
pass user alerts up the chain.
This implements https://bugzilla.gnome.org/show_bug.cgi?id=663527#c3.
Account reordering is now done by drag-and-drop instead of up/down
buttons.
Turned out to be a wee bit more complicated than I initially thought.
This scraps EAccountManager and EAccountTreeView and replaces them with
new classes centered around EMailAccountStore, which EMailSession owns.
EMailAccountStore is the model behind the account list in Preferences.
The folder tree model now uses it to sort its own top-level rows using
gtk_tree_path_compare(). It also broadcasts account operations through
signals so we don't have to rely so heavily on EAccountList signals,
since EAccountList is going away soon.
Also as part of this work, the e-mail-local.h and e-mail-store.h APIs
have been merged into EMailSession and MailFolderCache.
Drop EMFolderTreeModel's "session" property now that it has a "backend"
property and call em_folder_tree_model_set_backend() where we used to
call em_folder_tree_model_set_session().
The session can still be obtained through e_mail_backend_get_session().
All this so EMFolderTree can submit EActivity instances for async ops.
You can obtain an EMailSession from an EMailBackend, but not vice versa.
Creates lots of pretty ripples in the mail code, but ultimately reduces
complexity. So it's a code cleanup of sorts.
With unintrusive error dialogs gone, we can cut some unnecessary bits
out of EActivity.
I'm also adding a new enum property called "state", which is one of:
E_ACTIVITY_RUNNING
E_ACTIVITY_WAITING
E_ACTIVITY_CANCELLED
E_ACTIVITY_COMPLETED
The state of an activity must be explicitly changed. In particular,
when the user cancels an activity the state should be set only after
confirming the operation has been cancelled and not when cancellation
is requested (e.g. after receiving a G_IO_ERROR_CANCELLED, not when
the GCancellable emits "cancelled"). EActivityBar and EActivityProxy
widgets have been updated to make this distinction clearer in the UI.
E_ACTIVITY_WAITING will be used when activities have to be queued and
dispatched in sequence, which I haven't written yet.
