<div class="gmail_quote"><br>Grant and I discussed the imagej.plugin code and how it could be applied to ij.plugins. <div><br></div><div>The annotation based plugin framework is designed to serve two purposes:</div><div>Reduce Generic Dialog 'boilerplate' code in plugins</div>
<div>Decouple GUI parameters to enable chaining and headless operations</div><div><br></div><div>We looked at two specific examples to see how existing plugins would change by applying and adapting the imagej.plugin code.</div>
<div>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. </div>
<div><br></div><div> 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. </div>
<div><br></div><div> 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 <a href="http://dev.imagejdev.org/trac/imagej/ticket/207" target="_blank">trac</a> ticket.</div>
<div><br></div><div>Sincerely,<br><br>Rick Lentz<br>(608) 217 - 8592 (cell)<br>Bascom Hall - "...ever encourage that continual and fearless sifting and winnowing by which alone the truth can be found"<br>
</div>
</div><br><br clear="all"><br>