[ImageJ-devel] Extensions Classes
Curtis Rueden
ctrueden at wisc.edu
Thu Apr 22 13:43:09 CDT 2010
Hi Grant & Johannes,
Thanks for this discussion. Grant, to generalize Johannes's comment about
the Interactive interface, I am wondering about further detail for each
item. From the names alone I am having a hard time understanding the role of
some of them. I know this diagram is just a sketch, but I look forward to
seeing more detail in each box—short description of the function/purpose,
list of key fields & methods, etc.
-Curtis
On Thu, Apr 22, 2010 at 3:44 AM, Johannes Schindelin <
Johannes.Schindelin at gmx.de> wrote:
> Hi,
>
> On Wed, 21 Apr 2010, Grant B. Harris wrote:
>
> > I put together a preliminary sketch for a set of classes related to
> > Extensions, intended to spark more discussion:
> >
> >
> http://imagejdev.org/trac/imagej/attachment/ticket/15/Class%20Diagram.png
>
> I would suggest a few changes:
>
> - do not make a common interface for interactive extensions (otherwise,
> why is there no common interface for non-interactive extensions?
> besides, what would that common interactive interface contain?)
>
> - the interactive plugin should always just hand off to the
> non-interactive version of the plugin. If you do not require such a
> bonding, you will end up with non-recordable actions (or at least with
> the same problems with headless mode as we have right now)
>
> - do not special-case the stack processor. If you do that, you inherently
> restrict the Processor to 2 dimensions and you get the whole problem set
> of ImageProcessor vs ImagePlus vs ImageStack again. A processor should
> process images, whatever image you throw at it. It _may_ throw an
> exception (or indicate otherwise what it supports), but the extension
> interface is not the level at which you want to discern whether it
> handles 2D or >=3D.
>
> - do not couple the processor with the algorithm that strictly. It should
> be a 0..n connection. Algorithms offer a flexible Java-based API, while
> the extension should make it possible for application frameworks to
> discover user-specifiable parameters (sort of "AUI" -- application
> users' interface), so they are a different kettle than the extensions.
>
> From the list I sent to the Skype "channel", your diagram is only missing
> the way to specify menu entries. I really would try to decouple the menu
> entry specification from the actual action behind it, so the menu
> extensions would not be processors.
>
> Ciao,
> Johannes
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org
> http://imagejdev.org/mailman/listinfo/imagej-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20100422/ffe28348/attachment.html>
More information about the ImageJ-devel
mailing list