[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