Ticket #15 (closed feature: fixed)
Opened 2010-02-16T21:32:27-06:00
Last modified 2012-02-24T16:12:42-06:00
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
Change History
comment:2 Changed 2011-02-16T13:20:41-06:00 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.