[ImageJ-devel] Design meeting notes

[Johannes Schindelin]

Hi,

sorry, I am really tight on time at the moment, so I am not able to put 
much thought into this for now.

On Thu, 7 Oct 2010, Curtis Rueden wrote:

> > Related, some @parameters will be superfluous under some 
> > circumstances: as an example, CellProfiler's mixture of gaussians 
> > thresholding method asks "what percentage of the image is 
> > foreground?", but the Otsu thresholding method does not. CellProfiler 
> > does this by asking the module for the settings to display (and the 
> > user doesn't have to implement the method in which case all are 
> > displayed). How would such a method in ImageJ name the parameters to 
> > display? (string matching the field name? Tags in @parameters matching 
> > a string array returned by the method?
> 
> Hmm, sounds tricky. Maybe it work similarly to the idea above for 
> validation, where an interface method exists that reports, for each 
> parameter, whether it is currently relevant based on the values of other 
> parameters. A nice demo for this functionality might be as simple as an 
> "configure advanced options" checkbox that opens up a bunch more 
> options. When the box is unchecked, the advanced options all disappear.
> 
> Of course, allowing options to be grouped together would ease some of 
> the declarative burden, since you could group all the advanced options 
> into an explicit "advanced options" category.
> 
> Johannes, have you considered any of these ideas?

No. The time I spent on the plugin design since March, I have tried to 
come up with a sensible architecture to handle something like "Keep aspect 
ratio" feedback (without requiring the developer to provide a metric ton 
of methods to that end). So far, I haven't been successful (a single check 
method has the disadvantage that it cannot set the other number 
automatically).

Ciao,
Dscho