[ImageJ-devel] Abstract Plugin Meeting Notes: Draft, FYI Friday 17 September (0900-1025 CDT)

[Rick Lentz]

Grant and I discussed the imagej.plugin code and how it could be applied to
ij.plugins.

The annotation based plugin framework is designed to serve two purposes:
Reduce Generic Dialog 'boilerplate' code in plugins
Decouple GUI parameters to enable chaining and headless operations

We looked at two specific examples to see how existing plugins would change
by applying and adapting the imagej.plugin code.
The first example we looked at was ij.plugin.Animator.  Animator is called
by IJ.java's run() method using Executer.java.  The plugin implements a
PlugIn requiring public void run(string args).  At first we considered using
the imagej.plugin.RunnableAdaptor class to populate the Generic Dialog Box
in a manner similar to the earlier work on Example_PlugIn.java.  Thus, the
question arose on how to intercept control from the run(String args) call to
meet the needs of placing logic in the Runnable run() method used by
imagej.plugin.PlugInFunctions.

 We then thought we should find a better starting example so we looked at a
simple plugin, ij.plugin.CanvasResizer.  CanvasResizer uses the height and
width of the current image to populate the dialog box.  We considered using
ParameterHandler to get the fields and then modifying the prior to creating
the dialog with setParameter method call.

  This prompted us to consider other direct approaches of meeting the
headless/GUI Decoupled plugin approaches (E.g. Map<String, Object>)
requiring adapting the tasking outlined in the current
trac<http://dev.imagejdev.org/trac/imagej/ticket/207>
 ticket.

Sincerely,

Rick Lentz
(608) 217 - 8592 (cell)
Bascom Hall - "...ever encourage that continual and fearless sifting and
winnowing by which alone the truth can be found"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20100917/a8498644/attachment.html>