| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Because we now check for junk filtering software in configure, junk
filtering modules can now safely assume the required junk filtering
software is installed. No more having the module installed but not
the required software. If this invariant is broken, an error will
be shown for each new message received.
|
| |
|
|
|
| |
Avoid blocking the available() method with synchronous tests that,
it turns out, do cause a noticable delay.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the spamassassin and sa-learn programs cannot be found with
AC_PATH_PROG, configure will abort with an error message.
You can then either:
a) install the SpamAssassin software
b) specify the path with SPAMASSASSIN=/path/to/spamassassin and/or
SA_LEARN=/path/to/sa-learn
c) pass --disable-spamassassin to configure to exclude the module
This also drops the "spamc" and "spamd" GSettings keys.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
- Don't use the term "eplugin" for modules.
- Use the term "plugin" instead of "eplugin" for plugins.
- Split SpamAssassin settings into a separate schema.
|
| | |
|
| | |
|
| |
|
|
| |
I keep forgetting to not use G_PARAM_STATIC_STRINGS in modules...
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
References to EMailSession are leaking like crazy, so the module's
finalize() method never gets called, and we never kill our spamd.
Until I can track down all the reference leaks, kill the spamd process
in response to a "EShell::prepare-for-quit" signal instead of from the
module's finalize() method. (Maybe that's a better long-term solution
anyway?)
|
| | |
|
|
|
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.
|
