-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[experiment] Arrow snapping behavior #2924
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
I also share the frustration with arrows in cases like these. In general this feels a step in the right direction. I did find two kind of weird cases.
CleanShot.2024-02-23.at.16.56.08.mp4
CleanShot.2024-02-23.at.17.03.07.mp4Not sure if you already take proximity into account, but maybe there should additional weight if you start / end arrows near the edges of the shape? |
yeah agreed. i think if we can couple that with more nuanced hinting we can get something that feels really good. |
i'd love for this to be behind an experiment to play around with! i think i'd need to live with it for a while to see how it feels in general. |
I've started working through this. Core idea is interesting: should we make an arrow "imprecise" (pointing to the center) based on similarity of direction between line and center, i.e. is the user pointing toward the center or something else? There are a few other changes in this PR that make the question more complicated. Start / create arrowsFor example, a "create" arrow's "start" binding also binds in this way: ...and is also influenced by the user's current modifier state. Previously, I'd had the start arrow decision be made at the start, based on the user's action (modifiers, plus a pause indicating precision), and from there all modifiers effected only the end handle. I'd like to keep this focus on the end handle during a create phase, because alternatives felt (and feel in this PR) like modifying / re-writing a user's past decision. It's one of the more finer details in the app's interactions but important. more to come |
We could modulate that distance based on the pointer velocity. |
When I'm drawing diagrams I find that arrows snap a lot of the time when I don't want them to.
They often snap into states that aren't even close to what I was trying to achieve.
This PR tries to capture the intuition that if applying a snap makes the arrow shape wildly different than it was before, it's probably better not to snap.
Give it a go and lemme know how it feels.
Change Type
patch
— Bug fixminor
— New featuremajor
— Breaking changedependencies
— Changes to package dependencies1documentation
— Changes to the documentation only2tests
— Changes to any test code only2internal
— Any other changes that don't affect the published package2Test Plan
Release Notes
Footnotes
publishes a
patch
release, for devDependencies useinternal
↩will not publish a new version ↩ ↩2 ↩3