We may also want to consider a mouse action window/level mode - this is common in radiology viewers.

I agree -- and tooltips on the widget could be better too. Kilian made an additional request for a range widget that he could have an option to fine-tune the window/level settings, maybe with +/- adjustments. I think we should probably make our own range widget that fixes these comments... I'll assign this to myself for now...

Test note - if you get an email of this send me a confirmation email. -Steve

Another test note.

Can you attach a screenshot please, showing in which case you can't "grab" the slider?

For the last question: the slider itself is not sluggish (it doesn't do much actually), it's the code that is being triggered when the slider is moved that causes the delay. If that code is slow and is called on each RangeValueChangingEvent, then the user experience will be degraded. That is why we added a RangeValueChangedEvent event, which is only triggered when the user releases the button (i.e. is done with moving the slider). This is not real-time anymore per-se, but is designed to handle cases where the callback is just too slow.

Yes, Alex is working on the speed of the callback. The other issue Ron reported is that if the current range is small compared to the total range he can't grab the indicators.

OK I see the screenshot, and there is an obvious usability issue here, the range is taking probably about 30% of what already is a small left panel.
I would just put the Window/Level range below the "Window/Level: [AUTO]" elements so that it takes the full width of the panel. The vtkKWRange has an attribute that can be set so that the labels are on both ends of the range (so that it would not take too much vertical space).
I would decrease the height of the histogram canvas to balance the new layout.

Closing. Slicer3 is not being developed anymore.