Hi Dscho,<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">When you write that you want to kill ij.io.FileInfo, I hope you meant<br>
&quot;deprecate&quot; instead. A number of plugins use this class.<br></blockquote>
<br>Yes, sorry. The proposal remains to not change public API in ij.*, including FileInfo. By &quot;kill&quot; I meant, &quot;no corellary for FileInfo in the imagej.* package structure.&quot; This is mainly because Bio-Formats provides a generalized mechanism for solving the same problems (and more) that FileInfo does.<br>


<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
Also, I am wary of the MVC design discussions. This all sounds as if your<br>
target was again a single-desktop application, and not an image processing<br>
library extensible via plugins which just so happens to also have an<br>
interactive backend for end users.<br></blockquote>
<br>Unfortunately, the discussion wasn&#39;t well captured in the notes. Contrary to how it might have appeared, I think the desire for an MVC design actually illustrates our focus on &quot;ImageJ as library.&quot; The reality is that much of the engineering challenge of ImageJ *does* come down to how the GUI is structured, since many developers do want to leverage portions of the GUI (as a library) in their applications. So there are many layers to consider...<br>

<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
In other words, I get the impression that not everybody understood what<br>
the @parameter design is about. It is not about making writing plugins<br>
simpler -- that is a side effect. It is solely to support CellProfiler,<br>
KNIME, cluster and grid execution etc.<br></blockquote>
<br>I think Lee&#39;s quick usage of the design in CP definitely illustrates its power and convenience. We can chat more in person when I visit.<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">



Otherwise: impressive job.<br></blockquote>
<br>I think the discussion served more to get us all on the same (or at least similar) page, and thinking about these topics, than it did to make any substantial design progress. We did settle on our priorities for the conference presentation, at least, so that is good.<br>


<br>-Curtis<br><br><div class="gmail_quote">On Wed, Oct 6, 2010 at 5:42 PM, Johannes Schindelin <span dir="ltr">&lt;<a href="mailto:Johannes.Schindelin@gmx.de" target="_blank">Johannes.Schindelin@gmx.de</a>&gt;</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><br>
On Wed, 6 Oct 2010, Curtis Rueden wrote:<br>
<br>
&gt; A few of us met for several hours today to discuss some design issues<br>
&gt; for ImageJ 2.0. The original goal of the meeting was to begin defining a<br>
&gt; new core class hierarchy corresponding to many of ImageJ&#39;s historically<br>
&gt; most central classes: e.g., ImagePlus, ImageStack, ImageProcessor.<br>
&gt; However, we discussed several other architectural issues as well. I<br>
&gt; tried to take notes but they ended up being very terse. Nonetheless, I<br>
&gt; wanted to mention their availability at:<br>
&gt;<br>
&gt;<br>
&gt; <a href="https://docs.google.com/document/pub?id=13zVORIFldha5xT8C3wUPLPGr_ok30rh9whLrEsxYA_s" target="_blank">https://docs.google.com/document/pub?id=13zVORIFldha5xT8C3wUPLPGr_ok30rh9whLrEsxYA_s</a><br>
<br>
</div>When you write that you want to kill ij.io.FileInfo, I hope you meant<br>
&quot;deprecate&quot; instead. A number of plugins use this class.<br>
<br>
Also, I am wary of the MVC design discussions. This all sounds as if your<br>
target was again a single-desktop application, and not an image processing<br>
library extensible via plugins which just so happens to also have an<br>
interactive backend for end users.<br>
<br>
In other words, I get the impression that not everybody understood what<br>
the @parameter design is about. It is not about making writing plugins<br>
simpler -- that is a side effect. It is solely to support CellProfiler,<br>
KNIME, cluster and grid execution etc.<br>
<br>
Otherwise: impressive job.<br>
<br>
Ciao,<br>
<font color="#888888">Johannes<br>
<br>
</font></blockquote></div><br>