Extending Omea with New Resource Types

Plugin Possibilities and Responsibilities

Omea plugin context menu
enlarge

There are two main kinds of plugins that can be developed for Omea. The first, simpler kind of plugins, does not add any new resource types to Omea, but rather extends the functionality of the existing ones. The most common way for doing that is registering new actions - commands available in the menus, toolbars and through keyboard shortcuts - which work on resources of the standard types.

The screenshot on the right shows an email with a selected text fragment. You can see that the actions shown in the menu have been provided by multiple plugins. The actions highlighted in yellow have been provided by the Outlook plugin, the "New Task..." action - by the Tasks plugin, and the last item, "Look Up in Dictionary", has been provided by the Dictionary plugin which is a sample supplied with the Omea Open API documentation. The remaining menu items belong to the Omea core.

As the Dictionary plugin demonstrates, you can implement small and useful pieces of functionality with very little effort, and you don't need to learn the entire Omea Open API in order to do that. In fact, if you only understand how to register actions in the Omea UI and how to work with resources, you'll be able to implement a major portion of the features which have been suggested as plugin ideas by Omea users.

The second kind of plugins, which is the main focus of this article, extends Omea with entirely new resource types. Plugins of that kind usually add a new resource type tab to the Omea window, with new panels in the sidebars. Of course, plugins of the second kind can also register actions which are required to work with the resources of the new type.

A plugin which adds a new resource type interacts very closely with Omea core. Many of the core features only work on the resources provided by the plugin if the plugin took steps to support them. Other features do not require plugin interaction, but can be extended by plugins.

Omea plugin layout
enlarge

In general, Omea strives to reduce the amount of work that must be done by a plugin developer by providing a standard UI framework which the plugin only fills with data. There are some parts of the user interface, like the controls for viewing and editing resources, that must be implemented by a plugin, but as the picture on the right shows, the amount of such UI is relatively small. The parts highlighted in yellow are the interface controls implemented by plugins (the Outlook plugin and the Tasks plugin). The greenish-blue parts are controls implemented in Omea core which have been registered or filled with data by plugins.

Let us now go through the main features of Omea and discuss how they interact with plugins and how they can be extended.

Getting Resources into Omea. If the resources are created by the user, the plugin needs to provide the interface for creating and editing them. The standard resource editing window in Omea consists of a frame provided by the core (with the OK and Cancel buttons and the validation label) and an editing pane - a custom control implemented by the plugin.

If the resources get into the system automatically (imported from an external application or downloaded from the network), Omea provides a powerful set of asynchronous processing facilities that helps you write the downloading or import code.

Working with Resources. The minimum requirements for adding a resource type to Omea are:

Displaying Resource Lists. Plugins can display resource lists in regular (linear) or threaded mode. A plugin also has several possibilities to customize how resources of its type are displayed in a list. It can specify the columns that need to be shown by default, along with their default width. It can customize the way property values are converted to text (for example, task statuses are internally stored as numbers but displayed as strings) and the way resources are compared (for example, the "Re:" prefix is ignored when the resource list is sorted by subject). If that is not sufficient, a plugin can register a handler to perform custom drawing and event handling for a column. An example of a custom-drawn column is the "Annotation" column.

Plugins also provide the icons used to display the resources in resource lists and other places in the program. The icon used for a resource can depend on its state. There is a very easy to use system for specifying the property values and icons associated with them in an XML file. If the possibilities of that system are not sufficient, custom code can be written to return resource icons.

Searching Resources. To make the resources of its type searchable, a plugin needs to be able to provide the contents of its resources as a series of plain-text fragments. Fragments can be grouped in several sections (for example, subject, body and annotation), and the user can restrict searching to a particular section. Text indexing in Omea is asynchronous - the plugin queues its resource to be indexed, and then some time later a callback is called to retrieve the resource text. The same callback is used to retrieve text fragments when contexts for search results are displayed.

Another responsibility of a plugin is highlighting the found words in the resource text. That functionality is implemented by the embedded Web browser, so there is no extra work required if it is used to display the resource contents.

Omea plugin workspaces
enlarge

Workspaces. Resources of any type not marked as internal can be added to a workspace, but plugin support may be needed to make this actually useful. For example, when an Outlook folder is added to the workspace, the e-mails in that folder must also become visible in the workspace, along with the attachments of those e-mails. This is handled by registering the resource type as workspace-aware and specifying the link types which connect the resource to other resources which it "pulls" with itself when it is added to the workspace.

Plugins also have a limited capability to customize the user interface used to select which resources of a particular type should be shown in a workspace.

Categories, Flags and Annotations. These organization tools can be used on resources of any type which has not been marked as internal. Plugins can perform various operations with categories and automatically assign categories to resources. Plugins can also register additional flags and specify icons for them.

Omea plugin conditions
enlarge

Views. A plugin can register conditions which can be used to construct views and build advanced search queries. In most cases, conditions do not require custom programming. For example, the "Task is not completed" condition is registered simply as "Value of the Status property for resources of type Task is less than 2". For conditions which cannot be expressed as simple operations on resources and their links (for example, the "Sent only to me" condition), it is possible to write a custom class which will be called to check which resources match the condition and whether a given resource is a match.

Plugins can also register views built of conditions - either standard ones or those provided by plugins.

Rules. Rules are never invoked automatically by the Omea core. If it makes sense to process the resources of a plugin by rules, then the plugin needs to invoke the rule processor explicitly at the appropriate time. Plugins can also implement custom rule actions which accept a resource and a set of action parameters (for example, the folder where a received e-mail should be moved). The UI for editing the action parameters is provided by the core.

Clippings. In order to support clippings, the plugin needs to be able to return the current selection as a plain-text, RTF or HTML string. If the selection is not empty, it can be turned into a clipping. The standard embedded Web browser supports the interface for returning the selected text, so if the plugin uses it to display resources, there is no extra work required to support clippings.

Sending Resources. If a plugin needs a simple form of sending its resources as regular text emails (for example, "Send by Email" for bookmarks), it can invoke the standard service for creating e-mails. In Omea Reader, the e-mail service is implemented through the Simple MAPI interface, and in Omea Pro it uses the Outlook integration. If sending resources as text is not sufficient (for example, for contacts and tasks), the plugin can implement an interface for serializing its resources to an XML representation and restoring from that representation. Then it becomes possible to send those resources by email through the "Send Resources" feature.

« Page 1 2 3 4 5 »
Dmitry's photo

Dmitry Jemerov
JetBrains

The youngest of JetBrains project leads, Dmitry got his job after working on Syndirella, an open-source RSS reader. Dmitry always carries with him a Tablet PC with Omea running, and is always eager to demo it to anyone willing to listen. When not at work, he sometimes finds the time to ride his bike, play his bass and meet his friends for a role-playing game.

Contact Dmitry via email: dmitry(.)jemerov
(at) jetbrains.com