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">No. The time I spent on the plugin design since March, I have tried to<br>
come up with a sensible architecture to handle something like &quot;Keep aspect<br>
ratio&quot; feedback (without requiring the developer to provide a metric ton<br>
of methods to that end). So far, I haven&#39;t been successful (a single check<br>
method has the disadvantage that it cannot set the other number<br>
automatically).<br></blockquote><br>How about this:<br><br>    @Parameter<br>    public int width = 640;<br><br>    @Parameter(label = &quot;A double&quot;, digits = 3, columns = 5, units = &quot;microns&quot;)<br>    public int height = 480;<br>

<br>    @Parameter(label = &quot;Keep aspect ratio&quot;, callback = aspectRatioChanged)<br>    public boolean keepAspectRatio = false;<br><br>So that the developer defines their own callback methods for each parameter to which they want to react? Easy for each dialog implementation to attach listeners and callback by reflection, right?<br>

<br>-Curtis<br><br><div class="gmail_quote">On Sat, Oct 9, 2010 at 10:33 AM, Johannes Schindelin <span dir="ltr">&lt;<a href="mailto:Johannes.Schindelin@gmx.de">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>
<br>
sorry, I am really tight on time at the moment, so I am not able to put<br>
much thought into this for now.<br>
<div class="im"><br>
On Thu, 7 Oct 2010, Curtis Rueden wrote:<br>
<br>
&gt; &gt; Related, some @parameters will be superfluous under some<br>
&gt; &gt; circumstances: as an example, CellProfiler&#39;s mixture of gaussians<br>
&gt; &gt; thresholding method asks &quot;what percentage of the image is<br>
&gt; &gt; foreground?&quot;, but the Otsu thresholding method does not. CellProfiler<br>
&gt; &gt; does this by asking the module for the settings to display (and the<br>
&gt; &gt; user doesn&#39;t have to implement the method in which case all are<br>
&gt; &gt; displayed). How would such a method in ImageJ name the parameters to<br>
&gt; &gt; display? (string matching the field name? Tags in @parameters matching<br>
&gt; &gt; a string array returned by the method?<br>
&gt;<br>
&gt; Hmm, sounds tricky. Maybe it work similarly to the idea above for<br>
&gt; validation, where an interface method exists that reports, for each<br>
&gt; parameter, whether it is currently relevant based on the values of other<br>
&gt; parameters. A nice demo for this functionality might be as simple as an<br>
&gt; &quot;configure advanced options&quot; checkbox that opens up a bunch more<br>
&gt; options. When the box is unchecked, the advanced options all disappear.<br>
&gt;<br>
&gt; Of course, allowing options to be grouped together would ease some of<br>
&gt; the declarative burden, since you could group all the advanced options<br>
&gt; into an explicit &quot;advanced options&quot; category.<br>
&gt;<br>
&gt; Johannes, have you considered any of these ideas?<br>
<br>
</div>No. The time I spent on the plugin design since March, I have tried to<br>
come up with a sensible architecture to handle something like &quot;Keep aspect<br>
ratio&quot; feedback (without requiring the developer to provide a metric ton<br>
of methods to that end). So far, I haven&#39;t been successful (a single check<br>
method has the disadvantage that it cannot set the other number<br>
automatically).<br>
<br>
Ciao,<br>
Dscho<br>
<br>
</blockquote></div><br>