[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