Re: [Evolution-hackers] Moving EExtension to libedataserver
On Wed, 2011-09-07 at 13:07 -0400, Matthew Barnes wrote: Once 3.3 development is underway, one thing I'd like to do is promote the EExtension framework in Evolution to libedataserver as a replacement for e-data-server-module.c. Just to follow up, this is in 'master' now for 3.3.1. The EExtension framework now lives in libebackend and all the address book and calendar backends have been adapted to use it. The Evolution changes were relatively trivial -- mostly #include replacements. Worth noting is libeutil now links to libebackend. Let me know if there's any problems. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving EExtension to libedataserver
On Fri, 2011-09-09 at 22:18 -0400, Matthew Barnes wrote: I got this working today. Would anyone object if I create the gnome-3-2 branch early next week so I can commit this for 3.3.1 and then rebase my account-mgmt branch on it? Hi, I wouldn't do that, as it doubles work for translators, because it's their time now. Does it make that large difference to wait for next two weeks? You can always do those things locally and branchcommit later anyway. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving EExtension to libedataserver
Hi all, Am Montag 12 September 2011, um 09:57:26 schrieb Milan Crha: On Fri, 2011-09-09 at 22:18 -0400, Matthew Barnes wrote: I got this working today. Would anyone object if I create the gnome-3-2 branch early next week so I can commit this for 3.3.1 and then rebase my account-mgmt branch on it? Hi, I wouldn't do that, as it doubles work for translators, because it's their time now. Does it make that large difference to wait for next two weeks? You can always do those things locally and branchcommit later anyway. Bye, Milan Regarding the current plannings for porting evolution-kolab to a current dev version of Evo/E-D-S, it could prove very helpful to have this infrastructure available for basing our work on. We'd appreciate it much if the merge could be done as soon as the translator's window is closed and the merge can be done without foreseeable extra work for the release currently under preparation. Kind regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving EExtension to libedataserver
Hi there, just one bit of nitpicking: Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes: [...] The EExtension framework was introduced in Evolution 2.30 as part of the Shouldn't that read 2.32? At least, the wiki page says so. Kind regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving EExtension to libedataserver
Hi again, Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes: [...] The API is already fully documented and our wiki has usage instructions for it: http://live.gnome.org/Evolution/Extensions Is the list of EExtensible-tagged classes listed at the end of the wiki page up-to-date (and exhaustive) for the current dev version of Evo/E-D-S? I had a glance at the page since I'm trying to figure out whether or not the account setup stuff we're currently doing via EPlugin in evolution-kolab could instead be based on EExtensions (bearing in mind that EPlugin is going away sooner or later anyway). What's more, there are some Evolution UI extensions which we would like to implement for evolution-kolab, and since some of them are Kolab-specific, it seemed a better way to do it as an EExtension, rather than trying to hack Evolution directly. The questions at hand now are, do you see EExtension fit as an EPlugin replacement for account setup already, and can UI extensions (like additional entries in context menus or functional extensions of UI dialogs) already be done via EExtensions? Kind regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving EExtension to libedataserver
Hi, I hope I've got the reference right... Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes: [...] I'm going to need EExtension for the new D-Bus service I talked about recently [1] anyway, so it makes sense to get this part merged early. Kind regards, Christian [1] http://mail.gnome.org/archives/evolution-hackers/2011-August/msg00025.html -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving EExtension to libedataserver
On Mon, 2011-09-12 at 10:49 +0200, Christian Hilberg wrote: Am Montag 12 September 2011, um 09:57:26 schrieb Milan Crha: I wouldn't do that, as it doubles work for translators, because it's their time now. Does it make that large difference to wait for next two weeks? You can always do those things locally and branchcommit later anyway. Regarding the current plannings for porting evolution-kolab to a current dev version of Evo/E-D-S, it could prove very helpful to have this infrastructure available for basing our work on. We'd appreciate it much if the merge could be done as soon as the translator's window is closed and the merge can be done without foreseeable extra work for the release currently under preparation. Very well, we'll branch then when the hard code freeze begins as we usually do. The code freeze begins next Monday (September 19) after 2.91.92 tarballs are released. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving EExtension to libedataserver
On Mon, 2011-09-12 at 11:11 +0200, Christian Hilberg wrote: Is the list of EExtensible-tagged classes listed at the end of the wiki page up-to-date (and exhaustive) for the current dev version of Evo/E-D-S? Until 3.3.1 development begins, the extensible list only applies to Evolution. I'll give the list a refresh today, but you can also just grep the source code: git grep -l E_TYPE_EXTENSIBLE Classes are made extensible as-needed, and it's trivial to do so. I had a glance at the page since I'm trying to figure out whether or not the account setup stuff we're currently doing via EPlugin in evolution-kolab could instead be based on EExtensions (bearing in mind that EPlugin is going away sooner or later anyway). I think for now it's easier to go the EPlugin route and I'll help convert it when the time comes. I already have frameworks in place on my account-mgmt branch to convert all address book and calendar setup EPlugins to EExtensions (this reduces our reliance on EConfig, which I also intend to kill over the long-term). Mail account setup uses CamelProvider data structures with configuration details instead of EPlugins, which has its own share of problems but will likely survive a little longer. What's more, there are some Evolution UI extensions which we would like to implement for evolution-kolab, and since some of them are Kolab-specific, it seemed a better way to do it as an EExtension, rather than trying to hack Evolution directly. The questions at hand now are, do you see EExtension fit as an EPlugin replacement for account setup already, and can UI extensions (like additional entries in context menus or functional extensions of UI dialogs) already be done via EExtensions? It depends. One of the reasons I'm dismantling EPlugin is to discourage the tacking on of arbitrary features, because what you tend to get with that approach is an application that feels like it has a bunch of arbitrary features tacked on, rather than thoughtfully designed in. Another reason I'm dismantling EPlugin is that a lot of our existing plugins can be classified into natural extension points such as account configuration, importers, inline attachment display, etc. These types of plugins would be better served as extensions of a more formal API, which EExtensible and EExtension allows you to define. Before adding something to the user interface that you think is Kolab-specific, check whether the other groupware modules (Exchange, GroupWise, etc.) do something similar. If so, perhaps we can generalize what you and other groupware modules are trying to do and build a formal and extensible API for it directly into Evolution or E-D-S. It will have to be considered case-by-case. There probably are cases which are truly Kolab-specific, but I want you to have to invent as few wheels as possible. To answer your second question, menus and dialogs _can_ be extended via EConfig without relying on XML files, but it's a little more cumbersome. See the startup-wizard module in Evolution for an example: http://git.gnome.org/browse/evolution/tree/modules/startup-wizard/evolution-startup-wizard.c#n430 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving EExtension to libedataserver
On Mon, 2011-09-12 at 09:27 -0400, Matthew Barnes wrote: On Mon, 2011-09-12 at 10:49 +0200, Christian Hilberg wrote: Am Montag 12 September 2011, um 09:57:26 schrieb Milan Crha: I wouldn't do that, as it doubles work for translators, because it's their time now. Does it make that large difference to wait for next two weeks? You can always do those things locally and branchcommit later anyway. Regarding the current plannings for porting evolution-kolab to a current dev version of Evo/E-D-S, it could prove very helpful to have this infrastructure available for basing our work on. We'd appreciate it much if the merge could be done as soon as the translator's window is closed and the merge can be done without foreseeable extra work for the release currently under preparation. Very well, we'll branch then when the hard code freeze begins as we usually do. The code freeze begins next Monday (September 19) after 2.91.92 tarballs are released. Hi, it's 3.1.92, but anyway, it's hard-code freeze and still time for translators. I never much liked the early branching, as I know how pity it is to commit one change twice. Would it really make that big difference to wait one more week (it's those two, as I mentioned in my first mail here)? Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving EExtension to libedataserver
On Wed, 2011-09-07 at 13:07 -0400, Matthew Barnes wrote: Once 3.3 development is underway, one thing I'd like to do is promote the EExtension framework in Evolution to libedataserver as a replacement for e-data-server-module.c. On second thought, libebackend might be a better place for EExtension than libedataserver. Haven't decided yet, but it'll be one of the two. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
