| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
audio-inline, itip-formatter, prefer-plain, tnef-attachments
and vcard-inline plugins were converted to modules so that they
can fit into concept of the new formatter.
Every module still installs .eplug file, because there is no
suitable API at the moment to register plugins to the plugins dialog
and to extend the Preferences dialog.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
- Don't use the term "eplugin" for modules.
- Use the term "plugin" instead of "eplugin" for plugins.
- Split SpamAssassin settings into a separate schema.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
