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 _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
