Re: [Evolution-hackers] Moving EExtension to libedataserver

[Matthew Barnes <mbarnes redhat com>]

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