Hi Grant & Johannes,<br><br>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.<br>
<br>-Curtis<br><br><div class="gmail_quote">On Thu, Apr 22, 2010 at 3:44 AM, Johannes Schindelin <span dir="ltr"><<a href="mailto:Johannes.Schindelin@gmx.de">Johannes.Schindelin@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<div class="im"><br>
On Wed, 21 Apr 2010, Grant B. Harris wrote:<br>
<br>
> I put together a preliminary sketch for a set of classes related to<br>
> Extensions, intended to spark more discussion:<br>
><br>
> <a href="http://imagejdev.org/trac/imagej/attachment/ticket/15/Class%20Diagram.png" target="_blank">http://imagejdev.org/trac/imagej/attachment/ticket/15/Class%20Diagram.png</a><br>
<br>
</div>I would suggest a few changes:<br>
<br>
- do not make a common interface for interactive extensions (otherwise,<br>
why is there no common interface for non-interactive extensions?<br>
besides, what would that common interactive interface contain?)<br>
<br>
- the interactive plugin should always just hand off to the<br>
non-interactive version of the plugin. If you do not require such a<br>
bonding, you will end up with non-recordable actions (or at least with<br>
the same problems with headless mode as we have right now)<br>
<br>
- do not special-case the stack processor. If you do that, you inherently<br>
restrict the Processor to 2 dimensions and you get the whole problem set<br>
of ImageProcessor vs ImagePlus vs ImageStack again. A processor should<br>
process images, whatever image you throw at it. It _may_ throw an<br>
exception (or indicate otherwise what it supports), but the extension<br>
interface is not the level at which you want to discern whether it<br>
handles 2D or >=3D.<br>
<br>
- do not couple the processor with the algorithm that strictly. It should<br>
be a 0..n connection. Algorithms offer a flexible Java-based API, while<br>
the extension should make it possible for application frameworks to<br>
discover user-specifiable parameters (sort of "AUI" -- application<br>
users' interface), so they are a different kettle than the extensions.<br>
<br>
>From the list I sent to the Skype "channel", your diagram is only missing<br>
the way to specify menu entries. I really would try to decouple the menu<br>
entry specification from the actual action behind it, so the menu<br>
extensions would not be processors.<br>
<br>
Ciao,<br>
<font color="#888888">Johannes<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagejdev.org">ImageJ-devel@imagejdev.org</a><br>
<a href="http://imagejdev.org/mailman/listinfo/imagej-devel" target="_blank">http://imagejdev.org/mailman/listinfo/imagej-devel</a><br>
</div></div></blockquote></div><br>