-
-
Notifications
You must be signed in to change notification settings - Fork 443
Remove the reset_scroll_progress action and keybinding #7990
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
Conversation
Marked as draft so i can test with a mouse scroll wheel and not just trackpad. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7990 +/- ##
==========================================
+ Coverage 93.01% 93.05% +0.04%
==========================================
Files 648 648
Lines 61463 61448 -15
==========================================
+ Hits 57171 57182 +11
+ Misses 4292 4266 -26 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Behavior on scroll wheel is unaffected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tested locally and seems totally ok
References and relevant issues
Closes: #7232
Description
There is a strange
Reset scroll
viewer keybinding, which isn't clear what it does, but it is modifiable. It turns out it's connected to a hard-coded Control/Cmd-Scroll action to scroll through the dims.When scrolling, enough scroll needs to accumulate to trigger a slider movement. Then it's reset back to 0 and repeats. The Control/Cmd key needs to be held while scrolling, so what the
Reset scroll
keybinding is doing is reseting this accumulated amount back to zero, if someone stopped scrolling midway through a slice and then starts scrolling again.There is an issue though: The user can't change the actual modifier associated with the scroll action, so having only the reset be a changeable keybinding is confusing. If you change it, it effectively does nothing because you won't trigger it when trying to scroll the dims, which still triggers off Control/Cmd.
Further, doing this demonstrates that there is no issue, even with the scroll action having a "memory" of past fractional scrolling. After every step a reset already happens, so at most a fraction of a step when starting again is just not noticeable. If you were last scrolling forward, the next time you go to scroll you are slightly closer to the next slice--or further away from the previous one--sure, but in practice you don't notice it.
So I would argue that this confusing binding can just be removed. Which is what I do here.
This means I have to update the settings test that was using the keybinding because it was the first in the list, so I also did that.
Edit: using the first keybinding turned out to be in a lot of tests! And it wasn't always obvious. I added comments to make it easier to follow for the next time.