[ImageJ-devel] Design meeting notes

[Lee Kamentsky]

  On 10/12/2010 10:50 PM, Johannes Schindelin 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.)
>
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. Similarly 
with the value: I could include both the old and new values if 
necessary. Here, you could present the plugin developer with lots of 
information, anticipating that most developers would choose to ignore 
most or all of it.

I'm not as familiar with Java as you all, but perhaps it's best to 
either mimic the behavior of some existing model or use that model 
wholesale - 3 examples that come to mind are Java beans (has a property 
change event / listener / veto system), AWT events and Swing events.
> Ciao,
> Dscho
>
--Lee