EShellSettings predates GSettings and is no longer necessary.
GSettings allows binding GObject properties to GSettings keys,
with optional mapping functions. That fulfills the purpose of
EShellSettings.
Collect all the "config" extensions from the "addressbook", "calendar",
and "mail" modules into one place. These extensions typically just bind
GObject properties of extensible classes to app-specific GSettings keys.
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.
EMailConfigWebView is an extension that configures EWebView instances.
This used to cover both the email formatter and the email composer, but
with the email formatter now using WebKit/GTK+ and the email composer
still using GtkHtml, the composer was left unconfigured.
Add an EMailConfigWebViewGtkHTML extension that targets EWebViewGtkHTML
instances and applies the relevant settings, and remove all the GtkHTML
contortions from EMailConfigWebView.
The evolution-settings capplet was originally designed for Anjal, it was
used in MeeGo as part of the Express Mode effort, but doesn't really fit
in GNOME 3 nowadays (nor did it really fit in GNOME 2, in my opinion).
This is pretty clearly dead weight at this point. The MeeGo developers
have disappeared, and the remaining Evolution developers are not and do
not intend to maintain it. Plus it doesn't even build currently.
The evolution-settings capplet was originally designed for Anjal, it was
used in MeeGo as part of the Express Mode effort, but doesn't really fit
in GNOME 3 nowadays (nor did it really fit in GNOME 2, in my opinion).
Add a --with-capplet configure switch defaulting to 'no'. The capplet
will eventually be removed unless I see someone actively maintaining it.
Drop the "libevolution" prefix so it's not so verbose and also
consistent with upcoming evolution-data-server module libraries.
libevolution-module-foo.so --> module-foo.so
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.
We now have a proper junk mail filtering API. All junk filtering
extensions must subclass EMailJunkFilter for user preferences and
availability testing, and implement the CamelJunkFilter interface
for the actual junk filtering and learning operations.
The bogofilter module should be feature-equivalent to its former
EPlugin. The spamassassin module is far more complex. It's nearly
feature-equivalent to its former EPlugin, but I ditched the spamd
respawning code since it seemed unnecessary for a mail client to
have to deal with. If there's a huge outcry from users about it
I'll reluctantly put it back, but I don't expect one.
This gets us a step closer to killing off EConfig, and eventually
the EPlugin framework itself.
To reduce GConf usage in em-composer-utils.c:
- Relevant functions in em-composer-utils.c now take arguments for
reply and forward styles.
- Redundant forwarding functions were removed:
em_utils_forward_attached()
em_utils_forward_inline()
em_utils_forward_quoted()
- EMailReader now has "forward-style" and "reply-style" properties,
which get bound to the appropriate EShellSettings properties in
modules/mail/e-mail-config-reader.c. These same EShellSettings
properties are bound to the combo boxes in Composer Preferences.
- Require all EPlugin and EPluginHook subtypes be registered before
loading plugins. This drastically simplifies the EPlugin/EPluginHook
negotiation.
- Turn most EPluginHook subtypes into GTypeModules and register their
types from an e_module_load() function (does not include shell hooks).
- Convert EPluginLib and the Mono and Python bindings to GTypeModules
and register their types from an e_module_load() function, and kill
EPluginTypeHook.
- Collect all shell modules into a new top-level 'modules' directory:
$(top_srcdir)/modules/addressbook
$(top_srcdir)/modules/calendar
$(top_srcdir)/modules/mail
Nothing is allowed to link to these, not plugins nor other modules.
THIS SOLVES BUG #571275 AND OPENS THE DOOR TO PORTING TO MAC OS X.
- Mimic the libevolution-mail-shared library from master (except drop
the "shared" suffix) and have libevolution-mail-importers and all
mail-related plugins link to it.
- Discard the a11y subdirectories and have the files live alongside
their counterpart widgets.
