Don't auto-scroll horizontal drag-selection in the top/bottom rows#895
Open
hexbinoct wants to merge 1 commit into
Open
Don't auto-scroll horizontal drag-selection in the top/bottom rows#895hexbinoct wants to merge 1 commit into
hexbinoct wants to merge 1 commit into
Conversation
The drag-selection auto-scroll triggered whenever the mouse sat within the top/bottom (or left/right) scroll zone, regardless of where the drag began. Starting a selection in the top or bottom rows and moving only horizontally therefore scrolled the view vertically, which made a horizontal selection in those rows impossible. Anchor the scroll trigger to the drag start position: when a drag begins inside a scroll zone, the trigger point moves to the start, so movement along the other axis alone no longer scrolls, and the speed ramps up from where the drag began instead of snapping to full speed. When the drag begins outside the zones the behavior is unchanged. The scroll-speed calculation is extracted into a testable drag_scroll_speed function with unit tests covering the edge cases. Fixes microsoft#32
Author
|
@microsoft-github-policy-service agree |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #32.
Problem
While drag-selecting, the view auto-scrolls whenever the mouse is within the scroll zone near an edge (up to 3 cells). The trigger only looked at the mouse position, not at where the drag started. So if you start a selection in the top or bottom rows and move the mouse only horizontally, the view scrolls vertically, and a horizontal selection in those rows becomes impossible.
Fix
Anchor the scroll trigger to the drag start position. When a drag begins inside a scroll zone, the trigger point is pulled to the start position, so:
When the drag starts outside the scroll zones, the behavior is unchanged.
This follows the approach @DHowett and @lhecker outlined in the issue (trigger from
min(start, edge)/max(start, edge)rather than from the edge alone).Notes
The per-axis speed calculation, which used to be a closure inside the event handler, is now a small
drag_scroll_speedfree function. That made it possible to add unit tests for the edge cases: no scroll in the middle, edge-triggered scrolling from a middle start (unchanged behavior), no scroll when a drag in an edge zone only moves horizontally, and continued scrolling once the mouse passes the start position.Testing
cargo test -p edit --libpasses (46 tests, including the 4 newdrag_scroll_speedcases).cargo clippy -p edit --libis clean.cargo fmtclean on the changed code.