Posted by
Mike Cowperthwaite on
Dec 22, 2009; 5:40pm
URL: http://imagej.273.s1.nabble.com/Modeless-Adjust-windows-can-be-annoying-tp3689943p3689945.html
On 22-Dec-09 4:03 am, Gabriel Landini wrote:
> On Monday 21 December 2009, you wrote:
>> This leads to the following undesirable behavior: I have two images
>> open. On one, I set a threshold, then eventually close that image
>> window. The other image becomes "active." Then I click the Close
>> widget on the Threshold dialog, and suddenly my other image is
>> unintentionally thresholded. I now have to reopen the dialog, click
>> Reset, and then close it again.
>
> You need to press "Reset" before closing. Otherwise when you activate the
> thresholder (not surprisingly) the threshold will be computed and shown as a
> red LUT.
First, I shouldn't need to press Reset, because the image in question is
not thresholded at the time I close the Threshold window.
Furthermore, I simply do not agree with the "not surprisingly" part.
It's not surprising only to people who have grown used to this
surprising behavior. I'm curious if you know of any other program where
a change is performed in response to a window activation.
There is more to the problem. An image window that is minimized can
become "active" with absolutely no user cue to that effect. I close the
Threshold window, that image gets thresholded, and I don't find out
until I restore the window, at which point I *am* surprised and have to
stop thinking about my imaging problem in order to figure out what went
wrong -- did I restore the wrong image window? Have I lost an edit
somewhere?
>> I'm not sure how useful the automatic apply-on-activate-dialog feature
>> is, given the Apply button on the dialogs that does the same thing under
>> explicit user control.
>
> No, the apply button applies the computed threshold[...]
Right you are. However, the AUTO button *does* behave as I meant.
> If I understand correctly, the problem is that one needs to press Reset to
> "not show" it, so really one would be changing pressing one button for
> pressing another. There are many more presses to do to gather histograms than
> resetting the last one when closing the dialog. I would vote for leaving as it
> is.
You are under-stating the issue. One needs to (1) reopen the dialog,
(2) press Reset, (3) close the dialog *again* -- three steps.
But it's not a question of how many button presses. It's a question of
a program action being inappropriately tied to a user action. There is
an expected behavior when activating a window, but here that's been
overloaded in a non-obvious and problematic way.
Even if you're willing to accept that nonstandard behavior, I don't
think you can reasonably defend the auto-application of thresholding (or
Window/Level, Brightness/Contrast, Color Balance) when the dialog's
close button has been clicked -- that is just wrong.
> However, I wonder if on closing the dialog AND while on LUT (red or other)
> mode, the image LUT should be reset. That could prevent the issue you raised.
This is compounding the problem -- you are now introducing a second
instance of a program action being executed, unexpectedly, in response
to a standard user action, and it should be easy for you to come up with
cases where resetting the LUT on closing the dialog would cause problems
for some users.
--
Mike Cowperthwaite
Lathrop Engineering, San Jose CA