-
-
Notifications
You must be signed in to change notification settings - Fork 403
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 reset_start and reset_end to RangeToolLink #5848
Conversation
Codecov Report
@@ Coverage Diff @@
## main #5848 +/- ##
==========================================
- Coverage 88.24% 88.23% -0.01%
==========================================
Files 309 309
Lines 63915 63921 +6
==========================================
Hits 56402 56402
- Misses 7513 7519 +6
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 2 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
The code looks good to me and behaves in the way I would expect now.. see the video below. Screen.Recording.2023-08-08.at.7.10.49.PM.movNow when a user clicks the "reset" button in a Bokeh-backed plot, the axis range will revert to these specific values that were the range of the initial display, rather than the prior behavior which I think was ranging to the full data extents of the current data. Although I think this is the correct default behavior, a potential side effect is that if an application relies on the existing default behavior of the "reset" action, this might introduce unexpected behavior. I can't really think of an instance where this would be an issue, except for the case where data in the plot is updated or changes dynamically. Then, the reset_start and reset_end values will not be updated to the new data extents and the reset action may not show the entirety of the new data. I doubt this will be an issue and I think this PR corrects what should be the default behavior, but I added a suggestion to include an option to revert to the previous behavior. Otherwise, ready to merge |
The previous behavior was "only" introduced in 1.17 (implemented in #5800), so I feel no one has had time to rely on that behavior. I can, like you, not think of a reason why it would be relied upon. If you have set I would rather not add your suggested setting for this PR if you don't mind. If there is a demand for it, we can easily add it, but we cannot easily remove it if we add it to this PR. |
sounds good! |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This change will return to the bounds set when clicking the reset button.