On Thursday Dec. 16th, 2004 the Evolution Team is going to have an EPlugin Hackfest on irc in #evolution on gimp net. We want everyone to see just how cool EPlugin is, to help shake out bugs and implement those niggly little features you've always wanted. It should start around 10am Perth Australia time and go to about 5pm Boston time.

Plugin Hooks

Currently there are four major types of plugin "hooks" you can write against, each of which now has a sample in CVS.

1) Popup Menus (select-one-source)

You can add popup menu items to any popup menu in Evolution. You can add the item to all instances of the popup or mask it based on various criteria, for instance whether or not the folder is the "Junk" folder. The plugin is activated when the menu item is selected and you will receive relevant contextual information, such as the message being acted on.

2) Menus (save-attachments)

You can add menu items to components. The plugin is activated when the menu item is selected and you will receive relevant information like the currently selected folder.

3) Configuration (subject-thread)

You can add configuration items to any configuration dialogs in Evolution (well, calendar fully converted yet). You can add whole tabs or sections or insert an additional item into existing sections. The plugin is activated for you to insert your items and optionally to abort/commit/validate (for non-instant apply items).

4) Formatters (prefer-plain)

These are specific to the mailer, you can handle any mime type with a "formatter" or override existing behaviour. The plugin is activated when a message needs to display a relevant mime type and you will receive information such as the full message.

There is an additional plugin hook, "Events", currently we only have the "new mail" event for it.

Enabling Plugins

To enable plugins, you must be using the CVS mainline (2.1, part of GNOME 2.10) and you must enable plugins, --enable-plugins=all or --enable-plugins="list of plugin names"

Writing a Plugin

Plugins can be written in C or potentially in any mono language for this (the support for mono is still experimental). A basic plugin consists of two pieces, a .eplug xml definition file and a shared library implementing the plugin. The .eplug file contains the basic plugin information , such as the unique id of the plugin, the type (shlib or mono), the location (to the .so or dll) as well as the name and description of the plugin. Each plugin then lists the specific "hooks" its interested, for instance org.gnome.evolution.mail.bonobomenu:1.0, which is a menu hook for the mailer component, plugins can have more than one hook (see evolution/plugins/prefer-plain). Each hook type then has definitions specifc to it, for instance popup menus have a "menu" item with an "id" property that specifies the exact menu the plugin is modifying, followed by a list of "item"'s to be added to the menu.

Plugins receive function calls based on the .eplug definition for instance each popup menu has an "activate" property field that specifies the function to be called when the popup menu item is activated in the UI. The function calls into the plugin generally pass the plugin itself and the relevant target data structure.

More complete documentation can be found at http://www.gnome.org/projects/evolution/developer-doc/eplugin/.

Hackfest Ideas

A few ideas below to get you started, by no means an exhaustive list.

Plugins

• right click on a web calendar to refresh it
• right click on mail message to create task from message (mail-to-task)
• right click on mail folder can mark all messages as read
• tnef formatter (based on gtnef)
• right click on calendar folder to save it out to disk in icalendar format (save-calendar)
• right click on an imap mail folder to unsubscribe
• right click on an email address in a mail does a beagle/best search
• a formatter for open office that allows a user track versions of the same document
• emit dbus message when new mail arrives so beagle can update

Plugin Hooks

• look at converting event, task and addressbook editors to e-config so that UI items could be inserted/removed based on the backend
• add new events, possible ideas include "send", "quit", "folder deleted", "task completed"
• add a completely new hook, for instance to rewrite messages before they are sent

Standalone Plugin Development

An initial stand-alone plugin development project has been released, details can be found on The evolution developers blog site. This, together with a very recent source-code (cvs), will allow you to build a plugin as a separately distributable tar-ball and makes it easier to write and test plugins.

Copyright © 2004-2008 Novell Inc.