Use camel_session_list_services() instead of the internal store table.
The store table serves little purpose nowadays and could probably be
removed. I'll look into that later.
If we've just set up an NNTP account and haven't subscribed to any
folders yet, the folder_info tree may legitimately be NULL. Don't
treat it as an error.
Simplifies the code overall, since now we can bind widget properties to
settings properties and omit a bunch of callback functions. Plus now we
can initialize the settings widgets with proper defaults according to
the property specifications of CamelSettings classes.
Allows plugins to manipulate a CamelSettings instance directly. The
settings are written back to the URL string (for now) when the user
clicks Apply in the mail account editor.
Override CamelSession.add_service(). First chain up, then, if
initialization was successful, call camel_settings_load_from_url() on
the CamelSettings object in the new CamelService instance.
Note that eventually we'll load CamelSettings values from a key file
instead of from URL parameters. This is just a temporary measure.
The "account" property, if set, limits the displayed folder tree to the
corresponding CamelStore only. Useful in contexts where the choice of
folders should be limited to one particular store.
Some things are getting initialized too early. Not causing any bugs at
present, but it's bad form. Defer non-trivial initialization steps to
the constructed() method.
The itip-formatter part is clean, but the one for attachment_button
can still introduce runtime warnings, which requires more changes and
rethinking of this all, which I prefer to postpone, the best after
WebKit work will land, because it also may change most of the mail
formatting code (I guess). It doesn't crash, at least.
Calling camel_session_remove_services() while disposing of our
CamelSession instance can help break reference cycles and ensures
the CamelServices get finalized properly.
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.
