[Evolution-hackers] Extending Evolution

[Matthew Barnes <mbarnes redhat com>]

I've written a new framework for Evolution 2.31 that allows individual
object and widget classes to be extended through GTypeModule.

Simply stated, it's a new way to write plugins for Evolution which gives
you finer-grained control than EPlugin offers and doesn't involve nearly
as much scaffolding.

I've written up a "how-to" guide on the wiki complete with sample code.
For now, the framework is intentionally minimalistic and open-ended.  I
expect it will grow more sophisticated as we discover more use cases.

http://live.gnome.org/Evolution/Extensions


=== Motivation ===

I've been kicking this extension idea around for awhile, and even
prototyped it in a few places in Evolution (e.g. EAttachmentHandler),
but I hit some roadblocks in the work I'm doing on "express" mode and
decided this needed to be in place -now-.

With Anjal and now Annum reusing our shared libraries, our shared
libraries need to become much more "application-agnostic", particularly
with respect to user preferences.  These new applications need to be
able to apply their own set of user preferences without interfering with
Evolution's user preferences, and vice versa.

That means EShellSettings -- our central switchboard of user preferences
bound to Evolution-specific GConf keys -- needs to be regarded as
off-limits within libevolution-mail and libevolution-calendar.  This
will require some code-cleanup to fully realize, but the extension
system will help here.

Removing EShellSettings from libevolution-mail and libevolution-calendar
presents a problem for some of our "miscellaneous" widgets like
EDateEdit, whose behavior is influenced by user preferences:

   Time format: ( ) 12 hour (AM/PM)  (o) 24 hour

   [x] Show week numbers in date navigator

   Week starts on: [ Sunday ]

So every EDateEdit instance has to be configured according to these user
preferences.  EDateEdit can't do this itself because libewidgets (where
EDateEdit lives) can't link to libeshell (where EShellSettings and the
user preference values live).

My solution for Evolution 2.29 was to propagate EShellSettings to all
corners of the application and add configuration code every place where
we create or retrieve from GtkBuilder an EDateEdit instance.  This is
both cumbersome and error-prone.

With the extension system in place, Evolution's calendar module now
registers an EDateEdit extension that automatically configures each new
EDateEdit with the Evolution user preferences in EShellSettings.

I've repeated this for several other widgets.  More to follow.

So that's one long-winded use case.  Another use case relates to
desktop integration.

I've converted our NetworkManager connection monitoring code in
e-shell-nm.c to an EShell extension under /modules/network-manager.
This pattern can be repeated for integration with other network
monitoring software like ConnMan or Microsoft's "WLAN AutoConfig"
service.