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

Snap to origin and axis behavior for profile starts and segments #4344

Merged
merged 18 commits into from
Oct 31, 2024

Conversation

franknoirot
Copy link
Collaborator

@franknoirot franknoirot commented Oct 28, 2024

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:
Shows the test fails for expected reason on main

On this branch:
50 back-to-back runs passing on this branch on MacOS

Copy link

qa-wolf bot commented Oct 28, 2024

QA Wolf here! As you write new code it's important that your test coverage is keeping up.
Click here to request test coverage for this PR!

Copy link

vercel bot commented Oct 28, 2024

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

Name Status Preview Updated (UTC)
modeling-app ✅ Ready (Inspect) Visit Preview Oct 30, 2024 10:57pm

@franknoirot franknoirot added ux-papercut User experience paper cuts sketch labels Oct 29, 2024
code: string,
{
shouldNormalise = false,
timeout = 5_000,
}: { shouldNormalise?: boolean; timeout?: number } = {}
) => {
const wasPaneOpen = await this.isPaneOpen()
Copy link
Contributor

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

Copy link
Collaborator Author

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.

e2e/playwright/fixtures/sceneFixture.ts Show resolved Hide resolved
e2e/playwright/point-click.spec.ts Show resolved Hide resolved
Comment on lines +361 to +362
new Vector3(...sketchDetails.yAxis),
new Vector3(...sketchDetails.zAxis)
Copy link
Contributor

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?

Copy link
Collaborator Author

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/sceneInfra.ts Show resolved Hide resolved
Comment on lines 700 to 701
| { isDraft: true }
| { isDraft?: false; id: string; pathToNode: PathToNode }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is interesting.

src/clientSideScene/sceneEntities.ts Show resolved Hide resolved
Copy link
Collaborator

@Irev-Dev Irev-Dev left a 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)

src/clientSideScene/sceneEntities.ts Outdated Show resolved Hide resolved
src/clientSideScene/segments.ts Outdated Show resolved Hide resolved
@franknoirot
Copy link
Collaborator Author

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:

  1. X-axis = lineToY with 0
  2. Y-axis = lineToX with 0
  3. Origin = lineTo(0, 0)

@Irev-Dev
Copy link
Collaborator

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?

@franknoirot
Copy link
Collaborator Author

You're right @Irev-Dev, using lineTo feels better. I had angledLineToX and Y and that's the part I didn't like the feel of.

Screenshare.-.2024-10-30.10_08_08.AM-compressed.mp4

@franknoirot franknoirot merged commit 26e995d into main Oct 31, 2024
26 checks passed
@franknoirot franknoirot deleted the franknoirot/adhoc/snap-to-origin branch October 31, 2024 14:04
@franknoirot franknoirot mentioned this pull request Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sketch ux-papercut User experience paper cuts
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants