Skip to content
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

Arrow snapping behavior redux #3090

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Conversation

steveruizok
Copy link
Collaborator

@steveruizok steveruizok commented Mar 9, 2024

This PR makes a few small changes to arrow binding / center snapping. It incorporates some of the logic from #2924

It:

  • makes better use of pointer velocity when deciding whether to trigger an imprecise binding
  • incorporates the approximate "pointing-at-the-centerness" of the arrow when deciding whether to trigger an imprecise binding

Change Type

  • minor — New feature, though really this shouldn't break anything that isn't relying on quirks in our shapes / states

Test Plan

  1. Use the arrow tool.
  • Unit Tests

Release Notes

  • Improves the arrow shape's center-snapping logic

@huppy-bot huppy-bot bot added the minor Increment the minor version when merged label Mar 9, 2024
Copy link

vercel bot commented Mar 9, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
examples ✅ Ready (Inspect) Visit Preview Apr 29, 2024 9:27pm
tldraw-docs ✅ Ready (Inspect) Visit Preview Apr 29, 2024 9:27pm

@steveruizok steveruizok changed the title Arrow improvements [experiment] arrow improvements Mar 9, 2024
@steveruizok steveruizok changed the title [experiment] arrow improvements [experiment] arrow snapping behavior 2 Mar 9, 2024
@steveruizok
Copy link
Collaborator Author

steveruizok commented Mar 10, 2024

A key change here is making the "velocity at time of first binding" more decisive in whether to start in an imprecise or precise state. It's difficult to measure the "towards the centerness" of the arrow, but speed feels intentional (even on mobile). I also feel less in control of "time spent in the same binding". If we want to capture a "pause" intent, then we should start a timer whenever the velocity hits zeroish; and then I think we can reduce the amount of time it takes to trigger a pause.

Some of the "easy" actions are:

  • enter a shape
  • exit a shape
  • pause

The "harder" actions are:

  • point exactly at the center
  • point toward the center
  • control the velocity over time (ie keep the velocity slow while dragging inside of a bound shape)

By combining the harder intents with the easier actions, ie the velocity (or center-pointedness) at the time of entry, we can preserve the mode after that fact, and give a quick way of fixing the problem if in the wrong mode by leaving and re-entering, or by using a slightly less convenient mode (pausing, dragging to the center)

@steveruizok steveruizok requested a review from ds300 April 27, 2024 12:28
@steveruizok steveruizok changed the title [experiment] arrow snapping behavior 2 Arrow snapping behavior redux Apr 27, 2024
@steveruizok
Copy link
Collaborator Author

Bringing this out of experiment hell, now that a few other things have landed. (And want to be sure to get it considered before we redo arrow bindings).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
minor Increment the minor version when merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant