Fix of value_throttled in editable sliders

[hoxbro]

Fixes #2204

The error in #2204 was related to a missing edit_constant and the possibility of multiple events in _sync_value, which should now be fixed for the three editable sliders.

When looking / testing the editable sliders I could not get value_throttled to work with the _input_widget. To fix this, I changed the communication from jscallback to param.watch. Furthermore, I don't completely understand why in the current design it is possible to exceed the limit of the bounds with the _input_widget like

Current	This PR

I would expect the bounds to set to newer be exceeded, but it seems to be possible by design. Therefore, I have only implemented it for EditableIntSlider and EditableFloatSlider.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@4533a60). Click here to learn what that means.
The diff coverage is 10.00%.

@@            Coverage Diff            @@
##             master    #2208   +/-   ##
=========================================
  Coverage          ?   83.77%           
=========================================
  Files             ?      182           
  Lines             ?    21802           
  Branches          ?        0           
=========================================
  Hits              ?    18265           
  Misses            ?     3537           
  Partials          ?        0           

Impacted Files	Coverage Δ
panel/widgets/slider.py	75.50% <10.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4533a60...9c414c7. Read the comment docs.

[philippjfr]

Furthermore, I don't completely understand why in the current design it is possible to exceed the limit of the bounds with the _input_widget like

Very much by design indeed, there's many scenarios where this is useful. That said there's an argument to be made that this behavior should be togglable and/or it should restore the original bounds if you exceed the bounds and then restore them. @jbednar Any thoughts on that?

[hoxbro]

Added the functionality to be togglable:

[jbednar]

Thanks, but a single "exceedable" switch is not sufficent, because a widget needs to accept both exceedable and non-exceedable (hard and soft) bounds on both the lower and upper sides. A hard bound is an absolute limit -- it is an error to set the value outside those bounds. A soft bound or suggested range helps set the slider up to be useful, but can totally be exceeded if needed. Think about it as the soft bounds being for the user, helping the user have a slider that covers a useful range, and the hard bounds are for the program, making sure that the value never exceeds an allowed range so that the program doesn't crash (e.g. by avoiding negative numbers where they are not allowed).

So here, we don't want an "exceed bounds" flag, because (a) that would apply to both the high and low which many have different characteristics, and (b) just because we want people to be able to go outside the soft bounds doesn't mean we want them to be able to go outside all conceivable bounds; there are still often hard bounds to respect.

E.g. many physical quantities like length or mass or area never allow negative numbers and allow arbitrarily large values in theory, but for a given app there's some finite range that's typical (e.g. 10 to 100). So we'd set a hard bounds of 0,None and a soft bounds of 10,100. The slider would go between 10 and 100, while the spinner would allow any positive number. Without the "100" we couldn't get a slider (as we can't have a slider ranging up to infinity), but it's arbitrary; we just have to pick something, and then let the user override it. Without the 0 we'll have to have assertions or exception handling in our code to catch negative numbers. Only with both full hard and soft bound support can we handle everything.

See bokeh/bokeh#9943 for the full discussion.

[hoxbro]

I was not aware of the discussion behind this. I only looked at the development documentation, where the feature of exceeding start and end is not mentioned. So thank you for the detailed explanation.

I will remove the exceed_bounds asap and focus this PR on getting value_throttled working for the editable sliders.

[hoxbro]

Value throttled should now work for the editable sliders.

Code

import panel as pn


edit_float_slider = pn.widgets.EditableFloatSlider(name="Editable FloatSlider")


@pn.depends(edit_float_slider.param.value_throttled, watch=True)
def test_throttled_10(v1):
  print(v1)


edit_int_slider = pn.widgets.EditableIntSlider(name="Editable IntSlider", start=0, end=8, step=2, value=4)


@pn.depends(edit_int_slider.param.value_throttled, watch=True)
def test_throttled_11(v1):
  print(v1)


edit_range_slider = pn.widgets.EditableRangeSlider(name="Editable RangeSlider", start=0, end=8, step=2, value=(1,4))


@pn.depends(edit_range_slider.param.value_throttled, watch=True)
def test_throttled_12(v1):
  print(v1)


pn.Column(edit_float_slider, edit_int_slider, edit_range_slider,).servable()

Some notes / comments :

1. If I don't add value to _slider_widget, value_throttled do not work for edit_int_slider when going to zero:

• with value in slider_widget
  
• without value in slider_widget
  

2. EditableFloatSlider´s FloatInput properly need a format like EditableRangeSlider.
3. The EditableRangeSlider´s _end_edit should always be higher than _start_edit and the other way around