Track rotation with the hover region on rotatable widgets - #124
Conversation
The MouseRegion that reveals rotation handles sat outside the Transform.rotate, so its hit area stayed pinned to the unrotated footprint: hovering a rotated cone missed, and empty space where the widget used to be lit up. Moving the region inside the rotation keeps hover aligned with what is actually drawn.
|
@greptileai review |
📝 WalkthroughWalkthrough
ChangesRotated hover detection
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
lib/widgets/draggable_widgets/ability/rotatable_widget.dart (1)
112-122: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd a non-zero-rotation regression test.
Flutter's
Transform.rotateuses transformed hit testing by default, so this behavior needs coverage at a non-zero angle. (api.flutter.dev)The existing test in
test/rotatable_widget_hover_test.dartusesrotation: 0in Lines 16-90. It would pass ifMouseRegionremained outsideTransform.rotate. Add a case with a non-zero rotation. Move the mouse to a point inside the rotated target or handle area but outside the unrotated bounds. AssertShapeIndicatorFade.visibleandhandleDragStarted.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@lib/widgets/draggable_widgets/ability/rotatable_widget.dart` around lines 112 - 122, Add a regression test in rotatable_widget_hover_test.dart using a non-zero rotation, positioning the mouse inside the rotated target or handle area but outside its unrotated bounds. Assert that ShapeIndicatorFade.visible becomes true and handleDragStarted is triggered, covering transformed hit testing through Transform.rotate.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@lib/widgets/draggable_widgets/ability/rotatable_widget.dart`:
- Around line 112-122: Add a regression test in rotatable_widget_hover_test.dart
using a non-zero rotation, positioning the mouse inside the rotated target or
handle area but outside its unrotated bounds. Assert that
ShapeIndicatorFade.visible becomes true and handleDragStarted is triggered,
covering transformed hit testing through Transform.rotate.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: ea0a2f23-cde1-45af-8eae-55ba474722ce
📒 Files selected for processing (1)
lib/widgets/draggable_widgets/ability/rotatable_widget.dart
Greptile SummaryMoves the hover region inside the rotation transform so pointer hit testing follows the widget’s displayed orientation while retaining translucent interaction behavior. No product defect was established from the changed code. T-Rex validation blockedThe required Flutter toolchain is unavailable: Confidence Score: 5/5No correctness or security defect was identified in the reviewed change. The transform and hover-region ordering directly aligns the pointer region with the rendered widget while preserving the existing translucent hit-test configuration. Runtime widget validation could not execute because the Flutter toolchain is unavailable, but no final finding was established. Files Needing Attention: No additional files require changes.
What T-Rex did
Reviews (1): Last reviewed commit: "Track rotation with the hover region on ..." | Re-trigger Greptile |
What
Moves the handle-revealing
MouseRegioninsideTransform.rotateonRotatableWidget.Why
The hover region previously wrapped the rotation transform, so its hit area never rotated with the visual. On a rotated ability (e.g. a view cone), hovering the drawn widget could fail to reveal the rotation handles, while hovering the empty space of the unrotated footprint revealed them — hover felt detached from what's on screen.
With the region inside the transform, the pointer hit area is the same shape the user sees. The
translucent/non-opaque behavior is preserved so spatially separated handles stay reachable and pointer targets underneath aren't blocked.Testing
flutter analyzecleanSummary by CodeRabbit