Move the supporting widgets for the contact maps feature alongside
EABContactDisplay. Removing them from libeutil helps isolate our usage
of libchamplain so it's not imposed on the entire application, and even
3rd party software. That libchamplain is an optional dependency only
further complicates the matter.
Ideally I'd like to somehow isolate this feature in an extension module,
but we currently lack sufficient hooks for such an extension. So this
arrangement will have to suffice for now.
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.
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.
We have a confusing array of nearly-identical CFLAGS/LIBS definitions in
configure.ac. Time to simplify. Instead let's just have one definition
that includes all the libraries provided by Evolution-Data-Server (incl.
Camel). That, in combination with GNOME_PLATFORM, gives us most of what
we need for compliation and linking, and we can sprinkle definitions for
additional library dependencies in Makefile.am's as needed.
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().
There were a few places where we were accessing the folder tree model
directly to get the selected store + folder name, or were asking for the
selected URI only to parse back into its store + folder name components.
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.
I'm mainly trying to get rid of mail_get_folder(), but I'm also tired of
this plugin blocking the UI. If there's a lot of messages the lockup is
really noticable.
Global variables in shared libraries are a bad idea. EMailBackend now
owns the MailSession instance, which is actually now EMailSession.
Move the blocking utility functions in mail-tools.c to e-mail-session.c
and add asynchronous variants. Same approach as Camel.
Replace EMailReader.get_shell_backend() with EMailReader.get_backend(),
which returns an EMailBackend. Easier access to the EMailSession.
If we're using GTK+ 2.21.8 (where gtk_dialog_set_has_separator() is
deprecated but the property is still present and defaults to TRUE), we
still need to set the property to FALSE. So instead use g_object_set()
up through GTK+ 2.90.6, after which the property itself is gone.
Unfortunately the default value for this property is TRUE (bzzt, WRONG!)
so we can't just remove the function outright until we require GTK+ 2.22.
It was deprecated in GTK+ 2.21.8.
The EError mechanism is used both for error dialogs as well as basic alerts or
user prompts, so we should give it a more general name which matches this use.
This patch also cleans up a few includes of e-alert.h (formerly e-error.h) that
were not actually being used.
https://bugzilla.gnome.org/show_bug.cgi?id=602963
