fix: give the rotate handle its own cursor - #90
Open
FutuRiata wants to merge 1 commit into
Open
Conversation
The rotate handle is the only transform control that gives no hover feedback, because its cursor matches the canvas cursor exactly. Measured in a production build with getComputedStyle: canvas / scene grab rotate handle grab corner scale nwse-resize height / lift ns-resize So moving the pointer from empty space onto the rotate handle changes nothing on screen, while every other handle announces itself. A user cannot tell whether the next drag will rotate the shape or orbit the camera until it happens. The shared rule above already assigns a resize cursor to both handle families; only the later .rotate-handle block overrides it back to grab. pointer is the least opinionated fix: it means "interactive control" and, unlike grab, differs from the canvas. A dedicated rotation cursor would read better still, but that is a design decision. Reported by a user who ran into it while working, not while reading code.
mhaeu
pushed a commit
to mhaeu/SketchForge-3D
that referenced
this pull request
Sep 9, 2026
The rotate handle is the only transform control that gives no hover feedback, because its cursor matches the canvas cursor exactly. Measured in a production build with getComputedStyle: canvas / scene grab rotate handle grab corner scale nwse-resize height / lift ns-resize So moving the pointer from empty space onto the rotate handle changes nothing on screen, while every other handle announces itself. A user cannot tell whether the next drag will rotate the shape or orbit the camera until it happens. The shared rule above already assigns a resize cursor to both handle families; only the later .rotate-handle block overrides it back to grab. pointer is the least opinionated fix: it means "interactive control" and, unlike grab, differs from the canvas. A dedicated rotation cursor would read better still, but that is a design decision. Reported by a user who ran into it while working, not while reading code. Applied-from: Formsmith746#90 (upstream nicht gemergt) Applied-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
The rotate handle is the only transform control that gives no hover feedback: its cursor is identical to the canvas cursor.
Measured in a production build with
getComputedStyle:grabgrabnwse-resizens-resizeMoving the pointer from empty space onto the rotate handle changes nothing on screen, while every other handle announces itself. Until the drag starts, there is no way to tell whether it will rotate the shape or orbit the camera.
The shared rule at
globals.css:4733already assigns a resize cursor to both handle families; only the later.rotate-handleblock overrides it back tograb.pointeris the least opinionated fix — it means "interactive control" and, unlikegrab, differs from the canvas. A dedicated rotation cursor would read better still, but that is a design decision I did not want to make on your behalf.One line changed, plus a comment explaining why it is not
grab.Found by a user while working in the editor, not while reading the code.