Ticket #15 (closed feature: fixed)

Opened 10 years ago

Last modified 8 years ago

Design add-ons mechanism

Reported by: curtis Owned by: gharris
Priority: major Milestone: imagej-2.0.0
Component: Plugin Framework Version:
Severity: non-issue Keywords:
Cc: Blocked By:
Blocking:

Description

The idea of a "plugin" in ImageJ currently is well defined, though very general. Often, a suite of plugins go hand in hand and are bundled together; for example, the "LOCI Tools" plugins include the Bio-Formats Importer and Exporter plugins, Data Browser, Stack Colorizer, Stack Slicer, configuration and various other tools. Currently, ImageJ provides a mechanism to bundle multiple plugins into a single JAR file with a "plugins.config" file defining the relevant functionality. However, the scope of functionality possible with each plugin is limited, with each one generally relegated to a spot on the Plugins menu or submenu thereof.

We would like for such suites of functionality, tentatively called "add-ons" to ImageJ, to be more flexible in their presentation and integration with the core of ImageJ as well as its main user interface: I/O plugins automatically used as appropriate when image data is opened, and new GUI elements registered and added dynamically where appropriate, etc.

For example, LOCI could create an add-on to ImageJ for working with combined spectral-lifetime data, linking multiple views of different types (intensity images, lifetime decay histograms, spectral breakdowns, etc.) and responding to user interaction in each type differently. A tool like TrakEM2 could perhaps be packaged as an add-on as well.

One way to achieve this level of modularity may be with a dependency injection scheme such as  Guice, though it may also work well to provide a simple interface-driven design utilizing a robust event model.

Attachments

Class Diagram.png Download (22.4 KB) - added by gharris 10 years ago.

Change History

comment:1 Changed 10 years ago by gharris

  • Status changed from new to accepted

Changed 10 years ago by gharris

comment:2 Changed 9 years ago by curtis

  • Status changed from accepted to closed
  • Resolution set to fixed

In the simplest context, an "add-on" is simply a JAR file containing multiple plugins and tools (annotated with @Plugin and @Tool, respectively, and discovered by SezPoz).

For the functionality to be grouped together conceptually, we could create a metadata descriptor file that indicates that these components are all part of the same add-on. This information would mainly be used by the update mechanism (tentatively the Fiji updater) to group conceptually-related plugins, tools and modules together into a single "add-on" feature for easy installation.

Another way to create an "add-on" in the context of a NetBeans RCP application would be to bundle the functionality as an RCP module.

comment:3 Changed 8 years ago by curtis

  • Type changed from task to story

comment:4 Changed 8 years ago by curtis

  • Blocking 6 added

comment:4 Changed 8 years ago by curtis

The extensibility framework accomplishes this general goal. We are using ticket #11 as the central feature for linking together related tickets. So in a sense, this ticket is a duplicate of #11.

comment:5 Changed 8 years ago by curtis

  • Blocking 6 removed
Note: See TracTickets for help on using tickets.