Soft bounds for sliders

[jbednar]

IntSlider, FloatSlider, IntRange, and FloatRange all require a min and max value, to determine the bounds of the slider. Often, however, I want to set the bounds of the slider to "soft" bounds that are only suggestions or hints, not absolute boundaries. E.g. it's very common for me to have parameters that have a small "useful" range, say, 0 to 100, but a much larger legal range, say, 0 to 10000, or even 0 to infinity. It's fine to use a fixed min of 0 in this case, but there's no useful value for the max -- if I use a huge value, the slider won't go over a useful range, and if I use a small value, users are simply unable to choose values that should be legal, if they are typing directly into the text box.

Is there any way to support "soft" bounds soft_min,soft_max that will be respected if present, for setting up the slider start and end, but which are otherwise not enforced, while leaving the current hard-bound support as-is?

[jasongrout]

How do you imagine the UI works for this? The min and max set the bounds for the slider range. What would the UI be for a soft vs. hard bound? Especially a bound of infinity?

Perhaps a finite slider is not the right UI control for what you want? Maybe having a slider range over the 'soft' bounds, and an IntText box that ranges over the hard bounds, with a link between the slider and IntText when the values are legal for both?

[jbednar]

We implemented this behavior for TkInter and have been very happy with it for the past decade, so I know it's a well-defined request. :-) The logic is basically:

slider_left = soft_min if soft_min is not None else min
slider_right = soft_max if soft_max is not None else max

I.e., it's fine for the max to be infinity (i.e., None) as long as there is a provided soft_max to let the slider appear. This is actually a very common situation -- many parameters have no real upper bounds, but that's no reason that they can't have a slider!

What to do when someone types in a legal value in the text box that is outside the soft bounds can be debated, but what we did for Tkinter was to expand slider_right or slider_left to accommodate the new value. That usually seems to be what a user wants in practice, because it lets them expand the slider range when they need to.

In any case, yes, one can always have a slider and a separate text box, with the soft range used for the slider and the hard range used for the text box, but that makes user-level code quite complicated for such a common situation. Don't most parameters have no fixed upper bound in your own code? Size, length, magnitude, voltage, charge, power, force, mass, concentration, duration, etc., etc.?

[jasongrout]

Thanks for the extra detail. I'm still a little confused how this works. It sounds like you have a slider and two textboxes, and the slider covers the 'soft' range, and the text boxes let you adjust the slider bounds. Is that what you want? Something like:

from ipywidgets import IntSlider, IntText, HBox
from traitlets import link
x = IntSlider()
minvalue = IntText(layout={'width':'50px'})
maxvalue = IntText(layout={'width':'50px'})
link((x,'min'), (minvalue, 'value'))
link((x,'max'), (maxvalue, 'value'))
HBox([minvalue, x, maxvalue])

[jbednar]

Thanks for the code, but no, this is only a proposed change in the behavior of the current IntSlider and FloatSlider widgets (and their Range equivalents), not a proposal for any new widgets. The API would be precisely the same, apart from two new, optional, "soft_" values:

widgets.IntSlider(
    value=7,
    min=0,
    max=None,
    soft_min=None,
    soft_max=10,
    step=1,
    description='Test:',
    disabled=False,
    continuous_update=False,
    orientation='horizontal',
    readout=True,
    readout_format='i',
    slider_color='white'
)

And the appearance would be the same as always, with a single text box used for typing a specific value (not a range):

Even the behavior is the same as always, if people use min,max as they usually do, leaving soft_min,soft_max to their defaults of None. So it's a completely backwards compatible change.

There are then only two differences from the current behavior:

1. If at least one of soft_min or soft_max is specified, that soft value is used for the slider bounds, not the hard one.
2. If at least one of the min or max bounds is not specified (which is currently illegal for ipywidgets), that bound is not enforced for the text box, but that won't matter for the slider since we'll have the softbounds to use instead.

So, nothing has been lost, and the visual appearance is unchanged; the only difference is that when there is no actual bound semantically, ipywidgets will no longer erroneously be preventing users from selecting values outside the slider range. Right now, ipywidgets is forcing programmers to declare what is often an entirely arbitrary upper bound, unnecessarily limiting what their users can do with software that is developed for them.

[jasongrout]

Ah, thanks, now I think I'm understanding better. We could also call it something like readout_min and readout_max, with the constraint that the readout min/max was a superset of the min/max. A person could change the number in the readout to go beyond the slide boundaries if they wanted. Whether that changes the slide boundaries or not is a separate issue, like you said.

Am I understanding you now?

[jbednar]

Sure, that would work just as well -- leave min, max as the slider bounds, but then allow other bounds to be specified for the text box. That's also backwards compatible, and provides the same functionality. Thanks for following up on this so far!

[jasongrout]

Cool, I think we're progressing. I bounced the idea off of some other notebook users too, and it made sense to them too.

I think we should have some visual indication in the slider if the readout is outside the slider range.

Or perhaps when we get scales on the slider (showing the lower and upper bound), we make the lower and upper bound clickable.

What about rolling this issue into the issue exploring the idea of scales in the slider: #1153 and #1134.

[jbednar]

Whether to fold this issue in the others about improving sliders is up to you; thanks for investigating it in any case!

I'm not certain that readout_min and readout_max will work, now that I think about it, for reasons of backwards compatibility. Presumably those values would default to None, which for backwards compatibility should then mean "take the value of max and min". Otherwise, people would immediately start being able to put in out-of-range values in their existing slider code, which would be unsafe. Yet if None means "take the value of max and min", how would we express "has no upper (or lower) bound"? Inf would work for float types, but not int types. So I think the soft_max and soft_min proposed syntax would be a better approach for backwards compatibility.

[YuyQuan]

I would love to see this this feature implemented for doing calculations. It would be nice to have a slider to play with values within some sort of pre-defined limit while still having the ability to type in any number needed. As mentioned, this has been done elsewhere. Another example that comes to mind is Adobe After Effects, where an effect can give slider limits, but allows the user to enter values beyond it if need be.

[Alexboiboi]

Hi @jbednar,
I also like the idea a lot and see many use cases as you described. Mathematica has a nice way of dealing with values out of bounds for sliders. When the value is bigger than the max soft bound, the slider gets a red gradient towards the right side and the same happens when the set value is smaller than the min soft bound towards the left side.
If I am correct param/panel have this possibility.