[ImageJ-devel] Design meeting notes
Johannes.Schindelin at gmx.de
Wed Oct 13 10:06:05 CDT 2010
On Wed, 13 Oct 2010, Lee Kamentsky wrote:
> On 10/12/2010 10:50 PM, Johannes Schindelin wrote:
> > 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.)
> The obvious unique ID (signaling what changed) would be the field's name
> - I have enough Java reflection tools in CellProfiler at this point to
> be able to pick out the field name and include it in an event.
The problem I have with this solution: it does not catch problems at
compile time, but at runtime.
More information about the ImageJ-devel