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 email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers