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
Hi Matthew, Am Montag 12 September 2011, um 16:04:23 schrieb Matthew Barnes: > [...] > 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. Probably we should not head down the EConfig route, since in [1] you say that, "The new dialog windows will [...] NOT use EConfig. Not using EConfig is a *feature*. Means we're a step closer to killing it." Seems EConfig would not be that much of a stable ground anyone should settle on. :-) Kind regards, Christian [1] http://mail.gnome.org/archives/evolution-hackers/2011-January/msg00013.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 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 branch&commit > > > 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 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 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 branch&commit > > 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
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
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 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 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 branch&commit > 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
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 branch&commit 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
On Wed, 2011-09-07 at 13:43 -0400, Matthew Barnes wrote: > 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. 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? Indeed libebackend was the better place for EExtension. In addition, I created a few new classes in libebackend: EBackend EBackendFactory EDataFactory These new classes factor out some of the common pieces of their libedata-book and libedata-cal counterparts and serve as abstract base classes for them. Additionally, EDataFactory now handles all the module loading via EExtension -- completely replacing e-data-server-module.c. Obviously numerous API breaks here -- libebackend, libedata-book and libedata-cal are all affected. But it worked out to be a nice little API cleanup. ___ 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
