Posted by
Michael Schmid on
Dec 22, 2009; 7:35pm
URL: http://imagej.273.s1.nabble.com/Modeless-Adjust-windows-can-be-annoying-tp3689943p3689946.html
Hi Gabriel, Mike,
the current behavior of the threshold adjuster does not make me happy
either. Unfortunately, it is not so easy to cure the problem: When closing
the Threshold panel, it gets activated, and there is no elegant way to
find out whether a Close operation is imminent.
What could be done is changing the behavior in such a way that bringing
the Threshold panel to the foreground does not lead to automatic
thresholding of the current window. Immediate auto-thresholding would only
happen if the Threshold panel is opened (from the menu or via the keyboard
shortcut). Would this be ok?
[Wayne, in case you read this: what I have in mind is an additional
boolean argument 'doAutoThreshold' for the setup method; true when invoked
from the constructor, false when invoked from windowActivated]
Michael
_______________________________________________________________________
On Tue, December 22, 2009 18:40, Mike Cowperthwaite wrote:
> 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
>