[ImageJ-devel] Design meeting notes

[Curtis Rueden]

 Hi Lee,

So call depth = 1, respect the user's choice of parameters (which may be
> transitory if they are editing several at once) and indicate, but not
> prevent misconfiguration.
>

I agree that often it is best to err on the side of simply reporting invalid
inputs, rather than using convoluted schemes to prevent certain inputs
altogether.

However, in general we probably need to allow slightly more flexibility. The
example Johannes gave is a "Constrain aspect ratio" checkbox that forces the
width and height to retain a particular ratio. So all three parameters
(width, height and the aspect ratio checkbox) would need callback methods
that adjust either the width or the height depending on the checkbox's
status.

-Curtis

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

>  On 10/12/2010 10:07 AM, Curtis Rueden wrote:
>
>> Hi Lee,
>>
>>
>>  ...
>
>  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.
>>
>>  I'll use CellProfiler as an example here: the UI repaints itself after
> any change, with the validation callbacks fired, but the validation
> callbacks aren't allowed to change parameter values. The exception that they
> throw indicates the parameter that's most at fault for the problem, and some
> hopefully informative message about why.
>
> So call depth = 1, respect the user's choice of parameters (which may be
> transitory if they are editing several at once) and indicate, but not
> prevent misconfiguration.
>
> ---Lee
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20101012/a886f682/attachment.html>