feat(gestures): platform-appropriate pointer kind for drag - #117
Conversation
|
Warning Review limit reached
Next review available in: 43 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (7)
📝 WalkthroughWalkthroughThe drag tool accepts an optional ChangesDrag pointer kind
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant DragTool as interaction_toolkit drag handler
participant DragService as GestureInteractionService.drag
participant Dispatch as _dispatchDrag
DragTool->>DragService: pass mouse or touch PointerDeviceKind
DragService->>DragService: select explicit kind or platform default
DragService->>Dispatch: dispatch drag with selected kind
Dispatch->>Dispatch: apply kind to pointer down, move, and up events
Suggested reviewers: 🚥 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
packages/core/lib/src/commands/core_commands.dart (1)
404-405: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDocument why the default is platform-dependent.
State that the mouse default prevents default desktop scrollables from
competing with drag targets. State that touch intentionally preserves
scroll behavior. This is the design reason for delegating a null value to
the application.As per coding guidelines, “Always focus on WHY (key Design Decisions) it
does what it does in concise manner when adding Dart documentation comments.”🤖 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 `@packages/core/lib/src/commands/core_commands.dart` around lines 404 - 405, Update the Dart documentation comment for the pointer device kind option near the null platform-default behavior to explain why it delegates to the application: the mouse default prevents desktop scrollables from competing with drag targets, while touch intentionally preserves scrolling behavior.Source: Coding guidelines
🤖 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.
Inline comments:
In `@packages/core/lib/src/commands/core_commands.dart`:
- Around line 397-406: Replace the internal String contract for DragCommand.kind
with the shared DragPointerKind enum, keeping it nullable for the
platform-default behavior. Parse incoming JSON string values into
DragPointerKind before constructing DragCommand, reject or handle unsupported
values explicitly, and use kind.name only when serializing the extension
request.
---
Nitpick comments:
In `@packages/core/lib/src/commands/core_commands.dart`:
- Around line 404-405: Update the Dart documentation comment for the pointer
device kind option near the null platform-default behavior to explain why it
delegates to the application: the mouse default prevents desktop scrollables
from competing with drag targets, while touch intentionally preserves scrolling
behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 905f3bc2-30f4-43d3-85fd-87e75172516a
📒 Files selected for processing (7)
mcp_server_dart/lib/src/shared_core/command_executor.dartmcp_server_dart/lib/src/shared_core/commands/commands_catalog.dartmcp_toolkit/lib/src/services/gesture_interaction_service.dartmcp_toolkit/lib/src/toolkits/interaction_toolkit.dartpackages/core/lib/src/commands/core_commands.dartpackages/core/lib/src/tools/interaction_input_schemas.dartpackages/server_capability_core/lib/src/tools/interaction_tools.dart
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
packages/core/lib/src/commands/core_commands.dart (1)
406-410: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDeclare the parser's local types explicitly.
normalizedandkindrely on type inference. Declare them asStringand
DragPointerKindso the parser's types remain explicit.Proposed change
- final normalized = '$value'.trim().toLowerCase(); - for (final kind in DragPointerKind.values) { + final String normalized = '$value'.trim().toLowerCase(); + for (final DragPointerKind kind in DragPointerKind.values) {As per coding guidelines, “Explicit type declarations must be used.”
🤖 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 `@packages/core/lib/src/commands/core_commands.dart` around lines 406 - 410, In the parser containing the normalized value loop, explicitly declare normalized as String and the loop variable kind as DragPointerKind instead of relying on type inference; preserve the existing matching and return behavior.Source: Coding guidelines
🤖 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.
Inline comments:
In `@packages/core/lib/src/commands/core_commands.dart`:
- Around line 392-413: Complete the dartdoc for public DragPointerKind, its
mouse and touch members, and wireName with concise why-focused descriptions and
the required `@ai` annotations; explain that the enum keeps command state typed
and wireName is used only at the forwarding boundary. Update
parseDragPointerKind documentation to describe the value input,
normalization/unknown handling, and nullable null fallback.
---
Nitpick comments:
In `@packages/core/lib/src/commands/core_commands.dart`:
- Around line 406-410: In the parser containing the normalized value loop,
explicitly declare normalized as String and the loop variable kind as
DragPointerKind instead of relying on type inference; preserve the existing
matching and return behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 73f99039-8d48-4384-99db-be11d9e8a7e1
📒 Files selected for processing (4)
mcp_server_dart/lib/src/shared_core/command_executor.dartmcp_server_dart/lib/src/shared_core/commands/commands_catalog.dartpackages/core/lib/src/commands/core_commands.dartpackages/server_capability_core/lib/src/tools/interaction_tools.dart
🚧 Files skipped from review as they are similar to previous changes (3)
- mcp_server_dart/lib/src/shared_core/command_executor.dart
- packages/server_capability_core/lib/src/tools/interaction_tools.dart
- mcp_server_dart/lib/src/shared_core/commands/commands_catalog.dart
| /// Pointer device to synthesize for a [DragCommand]. | ||
| enum DragPointerKind { | ||
| mouse('mouse'), | ||
| touch('touch'); | ||
|
|
||
| const DragPointerKind(this.wireName); | ||
|
|
||
| final String wireName; | ||
| } | ||
|
|
||
| /// Parses a wire value into a [DragPointerKind]. Null, empty and unknown | ||
| /// values yield null — the app picks the platform default. | ||
| DragPointerKind? parseDragPointerKind(final Object? value) { | ||
| if (value == null) return null; | ||
| final normalized = '$value'.trim().toLowerCase(); | ||
| for (final kind in DragPointerKind.values) { | ||
| if (kind.wireName == normalized) { | ||
| return kind; | ||
| } | ||
| } | ||
| return null; | ||
| } |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Complete the dartdoc for the new public contract.
DragPointerKind and parseDragPointerKind are public. The comments do not
include the required @ai guidance. They also do not document the public
mouse, touch, or wireName members. The parser comment does not document
the value parameter or the nullable return value.
Add concise, why-focused /// documentation. Explain that the enum keeps
command state typed and that wireName is used only at the forwarding
boundary. Document the parser input and null fallback.
Proposed documentation
-/// Pointer device to synthesize for a [DragCommand].
+/// Selects the pointer device used by [DragCommand].
+///
+/// This keeps command state typed while preserving explicit wire values at
+/// the forwarding boundary.
+///
+/// `@ai` Use this enum for command state. Use [wireName] only when forwarding.
enum DragPointerKind {
+ /// Synthesizes mouse pointer events.
mouse('mouse'),
+ /// Synthesizes touch pointer events.
touch('touch');
+ /// Creates a pointer kind with its wire value.
const DragPointerKind(this.wireName);
+ /// The value used when this kind is serialized for forwarding.
final String wireName;
}
-/// Parses a wire value into a [DragPointerKind]. Null, empty and unknown
-/// values yield null — the app picks the platform default.
+/// Parses [value] into a [DragPointerKind].
+///
+/// [value] is the raw command-boundary value.
+/// Returns the matching kind, or `null` for null, empty, and unknown values.
+/// A `null` result lets the app select the platform default.As per coding guidelines, **/*.dart requires why-focused ///
documentation, an @ai annotation for public types, and documentation for
public members and parameters.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| /// Pointer device to synthesize for a [DragCommand]. | |
| enum DragPointerKind { | |
| mouse('mouse'), | |
| touch('touch'); | |
| const DragPointerKind(this.wireName); | |
| final String wireName; | |
| } | |
| /// Parses a wire value into a [DragPointerKind]. Null, empty and unknown | |
| /// values yield null — the app picks the platform default. | |
| DragPointerKind? parseDragPointerKind(final Object? value) { | |
| if (value == null) return null; | |
| final normalized = '$value'.trim().toLowerCase(); | |
| for (final kind in DragPointerKind.values) { | |
| if (kind.wireName == normalized) { | |
| return kind; | |
| } | |
| } | |
| return null; | |
| } | |
| /// Selects the pointer device used by [DragCommand]. | |
| /// | |
| /// This keeps command state typed while preserving explicit wire values at | |
| /// the forwarding boundary. | |
| /// | |
| /// `@ai` Use this enum for command state. Use [wireName] only when forwarding. | |
| enum DragPointerKind { | |
| /// Synthesizes mouse pointer events. | |
| mouse('mouse'), | |
| /// Synthesizes touch pointer events. | |
| touch('touch'); | |
| /// Creates a pointer kind with its wire value. | |
| const DragPointerKind(this.wireName); | |
| /// The value used when this kind is serialized for forwarding. | |
| final String wireName; | |
| } | |
| /// Parses [value] into a [DragPointerKind]. | |
| /// | |
| /// [value] is the raw command-boundary value. | |
| /// Returns the matching kind, or `null` for null, empty, and unknown values. | |
| /// A `null` result lets the app select the platform default. | |
| DragPointerKind? parseDragPointerKind(final Object? value) { | |
| if (value == null) return null; | |
| final normalized = '$value'.trim().toLowerCase(); | |
| for (final kind in DragPointerKind.values) { | |
| if (kind.wireName == normalized) { | |
| return kind; | |
| } | |
| } | |
| return null; | |
| } |
🤖 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 `@packages/core/lib/src/commands/core_commands.dart` around lines 392 - 413,
Complete the dartdoc for public DragPointerKind, its mouse and touch members,
and wireName with concise why-focused descriptions and the required `@ai`
annotations; explain that the enum keeps command state typed and wireName is
used only at the forwarding boundary. Update parseDragPointerKind documentation
to describe the value input, normalization/unknown handling, and nullable null
fallback.
Source: Coding guidelines
There was a problem hiding this comment.
Docs completed in a834cdb: enum purpose (typed command state, wireName only at the forwarding boundary), both values, wireName, and the parser's value input + null fallback.
Skipped the @ai annotation deliberately: there are zero @ai occurrences anywhere in this repository and I couldn't find a guideline file requiring it — neighboring public types (ScreenshotMode, parseScreenshotMode) carry no such marker either. If maintainers can point to the convention, happy to add it.
There was a problem hiding this comment.
@dipsy, thank you. The completed documentation addresses the substantive part of this finding.
The @ai requirement came from the configured Dart review guidelines, not from an existing repository convention. Your repository search is valid evidence that this requirement has no current precedent.
Please add the concise @ai guidance if the configured guideline is intended to apply to this repository. Otherwise, maintainers should remove or scope that guideline to prevent similar findings.
You are interacting with an AI system.
drag dispatched its pointer sequence without an explicit kind, so the events went out as touch. On desktop targets a touch drag almost never reaches the target's drag/pan recognizer: scrollables compete in the gesture arena and their directional recognizers accept at kTouchSlop (18 px along the axis) while a pan needs kPanSlop (36 px global), so a drag over a scrollable board scrolls it instead of moving the card. A real desktop user never hits this because scrollables don't track mouse drags at all (default ScrollBehavior.dragDevices excludes the mouse) — which is also why tap/long-press/hover here already synthesize mouse. Default the drag's pointer kind by target platform (mouse on desktop, touch elsewhere) and expose an optional `kind` argument end-to-end (schema, DragCommand, server forwarding, toolkit handler) for callers that need the other behavior. swipe keeps touch unconditionally — a fling relies on scrollables staying in the arena. The effective kind is reported in the drag result payload. Fixes Arenukvern#116. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Follow the command layer's enum-at-the-boundary pattern (ScreenshotMode, CoreConnectionMode, PermissionPolicy): parse the wire string once via parseDragPointerKind and carry the typed value through DragCommand; serialize back with wireName only when forwarding the extension request. Null, empty and unknown wire values stay "platform default" — the same observable behavior, now stated in the type. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
e04f520 to
bdaf793
Compare
dipsy
changed the title
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1 participant
Fixes #116.
What
dragdispatched its pointer sequence without an explicitkind, i.e. as touch. On desktop that hands the gesture to surrounding scrollables nearly every time: their directional recognizers accept atkTouchSlop(18 px along the axis) while the target's pan recognizer needskPanSlop(36 px global) — so dragging a card over a scrollable board scrolls the board. A real desktop user never hits this because scrollables don't track mouse drags (defaultScrollBehavior.dragDevicesexcludes the mouse);tap/long_press/hoverin the same service already synthesize mouse for exactly that reason.How
_dispatchDragtakes akindparameter (touch remains the default for the internal helper).GestureInteractionService.dragresolves the kind bydefaultTargetPlatform: mouse on macOS/Windows/Linux, touch elsewhere — the device a real user would drag with there. The effective kind is reported in the result payload.kind(mouse|touch) exposed end-to-end for callers that need the other behavior: shareddragInputSchema(),DragCommand, server forwarding (command_executor,commands_catalog,interaction_tools), and the app-side dynamic tool handler.swipekeeps touch unconditionally — a fling relies on scrollables staying in the arena.Testing
mcp_toolkit/test/interaction_toolkit_schema_parity_test.dart— green.packages/server_capability_core/test/tools/interaction_input_schemas_test.dart— green.Summary by CodeRabbit