[ImageJ-devel] Design meeting notes

Curtis Rueden ctrueden at wisc.edu
Tue Oct 12 09:07:00 CDT 2010


Hi Lee,

Hopefully, the plugin would get the context by specifying different
> callbacks for each parameter?
>

Yep, I think it would work.

You could also put in some sort of validation mechanism - the callback can
> throw an exception to reject the proposed change...
>

Good idea—solves both problems with one parameter.

The only tricky thing about this approach is how to handle programmatically
generated changes. For example, if widget A's value depends on widget B, and
both have callbacks... when user changes B, callbackB is called, which
programmatically changes A... should callbackA then be invoked? Either way
works—but if so, you have to be careful not to code mutual dependencies in a
way that generates infinite recursion.

-Curtis

On Tue, Oct 12, 2010 at 7:52 AM, Lee Kamentsky <leek at broadinstitute.org>wrote:

>  On 10/11/2010 3:11 PM, Johannes Schindelin wrote:
>
>> Hi,
>>
> ...
>
>      @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?
>>>
>> 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?
>>
>>  I'd pick a signature that was pretty generic. The callback implementation
> strategy might be to reevaluate everything when anything changed. For the
> above, if there were aspect ratio and some other parameter, say, "intensity"
> with log and linear options, you'd redo the whole image, applying the new
> aspect ratio and the new intensity transform.
>
> Hopefully, the plugin would get the context by specifying different
> callbacks for each parameter?
>
> You could also put in some sort of validation mechanism - the callback can
> throw an exception to reject the proposed change...
>
>> Ciao,
>> Dscho
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20101012/66d218e1/attachment.html>


More information about the ImageJ-devel mailing list