fix: show correct preview during unconstrained movement near a connection #454
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.
Proposed fix for #439
@microbit-robert @microbit-matt-hillsdon I'd appreciate your opinion on this.
Two parts to the change:
Initial offset
In

mover.ts, callinfo.updateTotalDeltaimmediately afteronDragStart.If the drag immediately shows a preview, this will update the block's location accordingly.
If a preview is shown, the block is moved down and to the right of the target connection.
Rationale
Without this change, the block was wrong about its position until the first constrained movement occurred. I think this change is necessary no matter what.
Offset during drag
In

keyboard_drag_strategy.ts, only force the block's position offset if the most recent movement was constrained.If the movement was unconstrained, the insertion marker still shows or hides as appropriate, but the dragging block can translate relative to the insertion marker. All of these become legal:




Moving away more causes the insertion marker to disappear:

And here's an example as a gif. All movements in this gif are unconstrained.

Rationale
In discussion with Robert and Matt I suggested making the drag step larger during keyboard drags, or making it larger only when showing a preview and trying to do an uncosntrained movement. But as the drag step size increases, so does the chance of missing a connection entirely. This is especially acute when working with value inputs, where the connections may be very close to each other in a row.
While investigating, I realized that part of the issue is that the user has no feedback: there is no visible change on the first unconstrained movement away from a connection (or, in MakeCode, the first four). In mouse mode the feedback is that the block moves along with the mouse pointer. The insertion marker sticks at the new position, but the dragging block moves around. In fact, this is half of the reason for using a separate insertion marker as a preview.
This change mimics mouse dragging by moving the dragging block around while still showing the preview. It may take multiple keypresses to move away from a connection, but users get feedback that a movement is happening.