-
Notifications
You must be signed in to change notification settings - Fork 45
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
Snap to origin and axis behavior for profile starts and segments #4344
Conversation
…ernion rotation issue)
QA Wolf here! As you write new code it's important that your test coverage is keeping up. |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
code: string, | ||
{ | ||
shouldNormalise = false, | ||
timeout = 5_000, | ||
}: { shouldNormalise?: boolean; timeout?: number } = {} | ||
) => { | ||
const wasPaneOpen = await this.isPaneOpen() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: isPaneOpen should probably be verb first: determineIfPaneOpen()
or similar and could be assigned to a var called isPaneOpen
or what more preferably paneState
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated to checkIfPanIsOpen
, I didn't do the paneState
thing this go because there are other notions of "state" in this class already, but we'll include something similar when we add a "serialise" function to the fixture as we need it.
new Vector3(...sketchDetails.yAxis), | ||
new Vector3(...sketchDetails.zAxis) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They weren't already Vector3s eh?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah they're [number, number, number]
type
src/clientSideScene/segments.ts
Outdated
| { isDraft: true } | ||
| { isDraft?: false; id: string; pathToNode: PathToNode } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is interesting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
Though I do have a product comment. To me when a user clicks on an axis, this is expressing enough intent that it should get constrained,in your demo, you click on the axis a couple times, but then when you edit it, a few of the points move back off the axis.
The way to do this would be instead of using line(...)
it should be lineTo(ZERO, 12.34)
(<- for the clicking the Y axis).
This would lock the segments to the axis even after editing.
What do you think? (sorry I know this is asking for more work if you agree with the above)
That's a fair point, and I actually did that at first it's super easy! I can make a follow-up branch to show you the behavior. It felt a little weird to me but it might be the right move. I actually had it mapping like:
|
Oh okay, I'm just thinking if I add something to an axis, I'd want it to stay there, but maybe that's just me. Maybe you can't because it's just a feeling, but are you able to expand on why it felt weird at all? |
You're right @Irev-Dev, using Screenshare.-.2024-10-30.10_08_08.AM-compressed.mp4 |
Adds non-configurable (for now) snapping behavior for point-and-click start points and segments. If the user mouses near either axis in screen-space, the value will snap to
0
instead of being some very small number.Demo
Screenshare.-.2024-10-28.7_08_31.PM-compressed.mp4
Test comparison
On
main
branch:On this branch: