Re: [Evolution-hackers] Regarding ESource and ESourceExtension

[Matthew Barnes <mbarnes redhat com>]

On Mon, 2012-10-08 at 23:56 +0900, Tristan Van Berkom wrote:
>     More specifically, I was under the impression that the
> ESourceExtensions were (at least partially) for the purpose of,
> well, extending the work flow and configurations provided by
> given backends.

Backend-specific settings live in a dedicated extension class for that
backend.  The key file groups are typically named "[$FOO Backend]".  You
can probably grep your own ~/.config/evolution/sources directory for
examples if you're running Evolution 3.6.0.

Not all backends currently have their own dedicated extension class.
I've been adding them as needed.  The local address book backend does
not yet, but the local calendar backend does:

http://git.gnome.org/browse/evolution-data-server/tree/calendar/backends/file/e-source-local.h

So we would add a similar class for the local address book backend to
hold the photo settings you mentioned.  (Some name juggling may have to
take place, since I unfortunately named the local calendar extension
merely "Local Backend" instead of "Local Calendar Backend".)


Also worth noting is backends don't utilize all available extensions.  
Some extensions are only used to hold settings for client-side features,
and are disregarded by backends.  Some examples:

ESourceAlarms -- [Alarms]

  Apart from the configuration UI, this extension is used only by
  evolution-alarm-notify to determine whether to show notifications for
  a particular calendar and to record the timestamp of the most recent
  notification for that calendar.

ESourceAutocomplete -- [Autocomplete]

  Apart from the configuration UI, this extension is used only by the
  ENameSelectorEntry widget to decide whether to query a particular
  address book when attempting to complete a partial email address. 
  This widget is used in the To/Cc/Bcc fields of Evolution's email
  composer.

Another example -- for 3.8 I'd like to introduce per-account new mail
notification options for Evolution by moving the options currently under
Edit -> Plugins -> Mail Notification to the Account Editor window.  This
will involve introducing a new ESourceNotification extension, which mail
backends would disregard since Evolution itself handles notifications.


Now our configuration UI story is a bit awkward at the moment because
the backend-specific "config" modules I mentioned previously live in
Evolution.  But because the backend-specific ESourceExtension classes
are not included in libedataserver's public API (that's intentional),
those classes have to be duplicated in Evolution.

In the case of the local calendar backend extension I pointed out above,
that same code also lives in Evolution's "cal-config-local" module:
http://git.gnome.org/browse/evolution/tree/modules/cal-config-local/e-source-local.h

Obviously this code duplication is suboptimal, but at least there exists
a formal settings API now, whereas under the old GConf XML system it was
just an ad-hoc string dictionary.

I plan to address the code duplication issue by eventually moving the
whole configuration UI framework and all the "config" modules down to
Evolution-Data-Server.  Then at least the config UI modules and the
backend modules can live together and share the extension classes.

Not sure if this fully addresses your question or not.  I'm still at a
bit of loss as to your use case.

Matthew Barnes