[ImageJ-devel] Design meeting notes

Curtis Rueden ctrueden at wisc.edu
Thu Oct 14 11:39:56 CDT 2010


Hi Dscho,

Just the infinite recursion thing (which is harder than meets the eye;
> you'd have to build a graph and detect circles).
>

Or we could invoke the callback only when the GUI changes by user action.

It's also not clear how the callback would signal to the dialog (be that
> an ImageJ, or a KNIME or CellProfiler dialog) _what_ value was changed by
> the callback. (Just think of the user changing the width, and the callback
> wanting to modify the height _iff_ "keep aspect-ratio" is checked.)
>

A given parameter's callback would be called only when the linked parameter
changes.

So the aspect ratio example might look like:

@Parameter(callback="widthChanged")
public int width;

@Parameter(callback="heightChanged")
public int height;

@Parameter(label="Maintain aspect ratio", callback="aspectRatioToggled")
public boolean aspectRatio;

/** The plugin must populate these with the current/initial width and height
choices. */
private int originalWidth, originalHeight;

/** Invoked when width text field changes. */
public void widthChanged() {
  if (aspectRatio) constrainHeight();
}

/** Invoked when height text field changes. */
public void heightChanged() {
  if (aspectRatio) constrainWidth();
}

public void aspectRatioToggled() {
  if (aspectRatio) constrainHeight(); // arbitrarily change height, rather
than width
}

/** Adjusts width to match original aspect ratio. */
private void constrainWidth() {
  width = originalWidth * height / originalHeight;
}

/** Adjusts height to match original aspect ratio. */
private void constrainHeight() {
  height = originalHeight * width / originalWidth;
}

After invoking the callback, the plugin infrastructure updates all dialog
fields to the latest values (and this update does not itself trigger any
additional callbacks).

-Curtis

On Tue, Oct 12, 2010 at 9:50 PM, Johannes Schindelin <
Johannes.Schindelin at gmx.de> wrote:

> Hi,
>
> On Tue, 12 Oct 2010, Curtis Rueden wrote:
>
> > > That was my first idea. But how would the user interface tell the
> > > callback without String or java.lang.reflect.Field ugliness which
> > > input was modified by the user (and by that, what field should be
> > > changed accordingly), and how would the callback tell that it changed
> > > something, and what?
> >
> > Each parameter has its own callback method, invoked when that particular
> > parameter changes. So as Lee said, which method is called indicates
> > which parameter was changed. (Perhaps it would be better to call the
> > attribute something like "onChange" instead.)
> >
> > Does that clarify it? Or is there a problem I'm not seeing?
>
> Just the infinite recursion thing (which is harder than meets the eye;
> you'd have to build a graph and detect circles).
>
> It's also not clear how the callback would signal to the dialog (be that
> an ImageJ, or a KNIME or CellProfiler dialog) _what_ value was changed by
> the callback. (Just think of the user changing the width, and the callback
> wanting to modify the height _iff_ "keep aspect-ratio" is checked.)
>
> Ciao,
> Dscho
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20101014/9ac164af/attachment.html>


More information about the ImageJ-devel mailing list