[ImageJ-devel] Design meeting notes

[Curtis Rueden]

Hi Dscho,

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).
>

How about this:

    @Parameter
    public int width = 640;

    @Parameter(label = "A double", digits = 3, columns = 5, units =
"microns")
    public int height = 480;

    @Parameter(label = "Keep aspect ratio", callback = aspectRatioChanged)
    public boolean keepAspectRatio = false;

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?

-Curtis

On Sat, Oct 9, 2010 at 10:33 AM, Johannes Schindelin <
Johannes.Schindelin at gmx.de> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20101011/c25065a4/attachment.html>