Repository navigation
fix: add inverted drag direction option for Y and height draginputs - #164
Open
Zohaib5677 wants to merge 1 commit into
Open
Zohaib5677 wants to merge 1 commit into
Zohaib5677 wants to merge 1 commit into
Conversation
Dragging a Y or height draginput vertically moved the shape opposite to the cursor: dragging down decreased Y/height, so the shape moved up while the cursor moved down. SVG's Y axis grows downward, so the value change must follow the cursor direction for these fields. Adds an `inverted` option to $.fn.dragInput (as proposed in methodofaction#163) that flips the drag, mouse-wheel and arrow-key direction, and applies it to all Y-position and height draginputs initialized in MD.Panel (canvas_height, rect_height, ellipse_cy/ry, image_height, circle_cy, selected_y, path_node_y, line_y1/y2, path_y, rect_y, g_y, text_y, image_y). Non-inverted fields keep the existing behavior. Also adds test/draginput_test.html (QUnit) covering default vs inverted drag direction and arrow keys, and registers it in test/all_tests.html. Fixes methodofaction#163
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.
PR DRAFT — methodofaction/Method-Draw
Target:
methodofaction/Method-Draw, branchfix/draginput-inverted-y-height→masterCommit: a18ce0d
Title
fix: add inverted drag direction option for Y and height draginputs
Body
Summary
Adds an
invertedoption to$.fn.dragInputthat flips drag, mouse-wheel, and arrow-key direction, and applies it to all Y-position and height fields.Problem
Dragging a Y or Height draginput vertically moved the shape opposite to the cursor: dragging down decreased Y/height, so the shape moved up while the cursor moved down. The same inversion affected the mouse wheel and arrow keys.
Root Cause
move()insrc/js/lib/jquery-draginput.jshard-codeddeltaY = (e.pageY - lastY) * -1("drag up = increase") for every field. That scrubber convention is wrong for Y-position and height fields because SVG's Y axis grows downward. The wheel and ArrowUp/ArrowDown handlers shared the hard-coded sign.Solution
invertedconfig option on$.fn.dragInput(name taken from the issue's proposal): drag delta sign becomes(e.pageY - lastY) * (inverted ? 1 : -1); arrow keys and wheel step flip accordingly. Also removed a duplicated"ArrowDown"key (behavior-preserving — the second definition was already winning).inverted: trueto all 16 Y/height draginput initializations insrc/js/Panel.js(the live init path viaMD.Panel()). X/width fields intentionally unchanged.src/js/method-draw.js(not loaded byindex.htmlor the gulp build) were deliberately left untouched.Testing
test/draginput_test.html(registered intest/all_tests.html), run headlessly against the repo's real jQuery: 4/8 before the fix (the inverted tests failing exactly as the bug predicts), 8/8 after, confirming default-direction fields are unchanged.git diff --checkclean.../editor/paths (pre-existing, unrelated).Risk and Compatibility
Low. Opt-in flag; behavior of all non-inverted fields is unchanged (verified by test). The direction change for Y/height fields is intentional and user-visible, per the issue's proposal.
Related Issue
Fixes #163