-
-
Notifications
You must be signed in to change notification settings - Fork 489
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add hard bounds to editable sliders #3739
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3739 +/- ##
==========================================
+ Coverage 83.69% 84.11% +0.42%
==========================================
Files 209 211 +2
Lines 30053 30540 +487
==========================================
+ Hits 25152 25690 +538
+ Misses 4901 4850 -51
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Looking good to me! Not entirely sure Separately I think this PR should also update the |
I don't favor Some suggestions for another name: pinned, immovable, locked, strict, firm. |
I think "hard bounds" is self-explanatory; that's something people say in the real world. But "hard_end" doesn't really work. It can't be a tuple to avoid that problem? I don't think "editor" is the right concept, certainly not at the Param level but it also seems odd to me at the Panel level. "Soft bounds" are really "suggested bounds", i.e., they are a weak suggestion of a useful range, a hint that doesn't specifically have to do with editors or widgets, but a declaration that the author of this app thought that this range was useful or the best starting point. Such a suggestion maps nicely to the initial bounds of a widget, but that's not its only interpretation. |
[Oops; hit close accidentally!] |
For compatibility with other sliders the How that maps onto the |
I like better One note, the docs will have to be updated, this is e.g. the current definition of the
By the way are we okay with the fact that if (That's another issue but the Input number widgets don't seem to have a way to indicate their bounds) |
I would have assumed that any previously supported single bounds would have to be hard bounds, and that any new set of bounds are optional soft bounds that override the previous bounds if present. Isn't that the only way the system can behave reasonably? |
I'm actually okay with |
When updating the documentation, I updated a small bug, which meant that the screenrecord-2022-08-09_15.37.53.mp4The |
A couple of UI tests would be super nice, otherwise this looks ready to merge. |
Looks like one of the tests is flakey. Can you see if you can fix it? Otherwise use the flaky marker with max_runs=3. There also seems to be an unrelated VTK issue on Windows. |
Thanks, merging (py 3.9 failure still unrelated). |
Fixes #3637
The way to set the hard bounds is by using
fixed_start
andfixed_end
, which are then set on thevalue
parameter as bounds andstart
andend
of the text input widgets. The reason for using two parameters and not one is to mimic how the widgetstart
andend
work.I tried to set the
bounds
of thevalue
parameter of the non-editable sliders to fix the #2735, but it broke a lot of the tests, so I removed it again (for now).The removal of
self._slider.jscallback
is because it didn't seem to do anything, but maybe it is to avoid multiple synchronizations between the bokeh model and the param class. I will add it back again with a comment if needed.The last thing is on the
EditableRangeSlider
, I set the start value of the text input always to be smaller than the end value and vice versa.