Re: [Evolution-hackers] Beginner
Hey, Hi, that's awesome, welcome! There are some resources here [0], though some might be slightly out-dated. If you want to start hacking you can pick some of the gnome-love bugs [1] - they are small, usually simple to fix bugs aimed for beginners. Thanks a lot. I checked the resources. They are quite helpful. Also all devs hang out on IRC, so I suggest you also join our #evolution channel on irc.gimp.net. If you need any help with the bug you choose, you can ask there too. I'll probably need some help choosing the bugs I would like to work on. IRC sounds fine. Thanks. Cheers, Dan [0] https://live.gnome.org/Evolution/ [1] https://bugzilla.gnome.org/buglist.cgi?keywords=gnome- love;query_format=advanced;keywords_type=allwords;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;product=Evolution;classification=Applications Thanks a lot. Regards, Sakchhi -- -- dvra...@redhat.com | Associate Software Engineer / BaseOS / KDE, Qt GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Regarding ESource and ESourceExtension
Hi again, I've been looking deeper into the details of creating addressbooks and using fancy extensions and I have another question/issue, that would be: How do you ask a backend if it supports a given extension ? Currently, as far as I can see it's possible to blindly add extensions to sources and not know if they are indeed supported, like this: source = e_source_new_with_uid (); backend = e_source_get_extension (source, E_SOURCE_EXTENSION_ADDRESS_BOOK); /* Create our addressbook with the backend this tool was * configured to use: */ e_source_backend_set_backend_name (backend, abstract backend name); /* Add our awesome configuration values, we hope that this * backend supports the feature set provided by EAwesomeExtension: */ awesome = e_source_get_extension(source, E_SOURCE_EXTENSION_AWESOME); e_awesome_extension_configure(awesome, E_AWESOME_DO_IT_AWESOMELY); /* Hmmm... I hope this addressbook is indeed awesome, * but I can't know for sure... */ e_source_registry_commit_source (); Is it intended that the frontend must know what extensions are supported by a given backend ? Perhaps a generic backend property could essentially be used to check which extensions are indeed supported by a given backend, i.e. after the backend is actually opened ? (not sure that that approach would be ideal, perhaps backends could install something for the registry to read at build time, indicating what extensions are supported by the freshly built backend...). Cheers, -Tristan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Regarding ESource and ESourceExtension
On Mon, 2012-10-08 at 18:40 +0900, Tristan Van Berkom wrote: Is it intended that the frontend must know what extensions are supported by a given backend ? What extensions are you worried about, specifically? And what's the use case for configuring them by hand? This page explains which extensions are typically present in a given type of key file: https://live.gnome.org/Evolution/ESourceFileFormat The various config modules in Evolution [1] serve as configuration backends for the account editor and the New Address Book and New Calendar dialogs. Each module knows what extensions are supported by its respective Camel/E-D-S backend. Matthew Barnes [1] http://git.gnome.org/browse/evolution/tree/modules ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Regarding ESource and ESourceExtension
On 10/08/2012 08:55 PM, Matthew Barnes wrote: On Mon, 2012-10-08 at 18:40 +0900, Tristan Van Berkom wrote: Is it intended that the frontend must know what extensions are supported by a given backend ? What extensions are you worried about, specifically? And what's the use case for configuring them by hand? Hi again Matthew, 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. For instance, currently the address book backends report capabilities and supported fields via the EBookBackend properties, providing a way for frontends to see what is possible to do with the given backends that they are using (or predict how it will react when asked to do something specific). It seems rather tempting (and clean) to go with the extensions as a method of adding custom configuration to some, but not all backends. One simplistic example of the usefulness in this would be, you could potentially tell the local addressbook backend that it should transform incoming photo contact fields into local uris, or prefer not to, and even specify a local directory where the sysadmin/user might chose the photos should be stored, however this extension would only make sense for the local addressbook. Of course it would be nice if, additionally, the tooling around this would be able to automatically detect which extension was available on which backend. For the simplistic example above, it would enable a hypothetical addressbook interaction tool, at creation time, to decide whether to display a file selector to decide where photos should be stored on disk, but only if Local Address Book was selected as the storage type of the addressbook being created. Best Regards, -Tristan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Regarding ESource and ESourceExtension
Am Montag, den 08.10.2012, 07:55 -0400 schrieb Matthew Barnes: On Mon, 2012-10-08 at 18:40 +0900, Tristan Van Berkom wrote: Is it intended that the frontend must know what extensions are supported by a given backend ? What extensions are you worried about, specifically? And what's the use case for configuring them by hand? Like Tristan wrote we currently evaluate some ideas for improving cooperation of applications and backends, without spoiling the API with much clutter that's only meaningful to a few backends. ESourceExtension seemed like a perfect fit for that purpose. This page explains which extensions are typically present in a given type of key file: https://live.gnome.org/Evolution/ESourceFileFormat Thanks a lot for this link! We already wondered about the details of the source file format. The various config modules in Evolution [1] serve as configuration backends for the account editor and the New Address Book and New Calendar dialogs. Each module knows what extensions are supported by its respective Camel/E-D-S backend. Is it wise to have such tight coupling? I'd suspect such tight coupling makes things harder for environments that can make good use of EDS, but where Evolution UI (or in the long term GOA?) doesn't fit. Like for instance mobile devices. Shouldn't there be some API that provides introspection of supported backends and their features? Ciao, Mathias ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Regarding ESource and ESourceExtension
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 evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Regarding ESource and ESourceExtension
On Mon, 2012-10-08 at 14:42 -0400, Matthew Barnes wrote: Not sure if this fully addresses your question or not. I'm still at a bit of loss as to your use case. One example would be SyncEvolution, configuring and using additional features in EDS if and only if they are supported. If that cannot be detected at runtime, then one of several much less attractive workarounds must be used: * configure option in SyncEvolution - which users will get wrong * detect version of EDS and its backend (not even sure whether that works with enough granularity) and map to hard-coded list of capabilities - will be difficult to keep up-to-date -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
