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. _______________________________________________ Evolution-hackers mailing list Evolutionemail@example.com http://mail.gnome.org/mailman/listinfo/evolution-hackers