Move every shape gizmo onto a registry-driven generic system by Ayush2k02 · Pull Request #4479 · GraphiteEditor/Graphite

Ayush2k02 · 2026-08-26T13:30:25Z

Replaces the per-shape gizmo handlers with a registry that nodes declare into.

gizmo_registry.rs: node type to the parameters worth exposing. Each entry has the
parameter index, control type, name, bounds and position hint.
generic_slider_gizmo.rs / generic_dial_gizmo.rs: the two controls. State machine,
hit-testing, hover arbitration, cursor and graph write live here.
gizmo_behaviors.rs: per-shape overrides for grab points, hover distance, drag,
snapping and overlays. Eleven definitions cover seven shapes.
README.md: how to add a gizmo to a node.

Migration:

All seven shapes on the registry. 14 gizmos, 11 ported from the old handlers with
unchanged behaviour.
shape_gizmos/ deleted: roughly 2K lines across six handlers.
ShapeGizmoHandlers goes from seven variants to two.

New:

Heart cleavage and shoulder handles.
Sliders with no overlay of their own now show their grab points at rest.

Fixes, found by hand rather than by the test suite:

Polygon spokes, dial step size, dial hide check: regressions from the migration.
Circle and arc radius drag: collapsed on a left-edge grab, snapped when grabbed
off-centre, and moved on a click that never moved. Now reads horizontally.

Includes the Heart node commits as a base.

1-polygon-sides-dial.mp4

2-star-radius-snapping-and-points-dial.mp4

3-circle-radius.mp4

4-arc-radius.mp4

5-arc-sweep-endpoints.mp4

6-spiral-turns.mp4

7-grid-rows.mp4

Regression from master ( CIrcle and Arc radius bug )

Screen.Recording.2026-08-26.at.6.53.34.PM.mov

…ter APIs

…gration

… grid drawing a stray handle

…urve

cubic-dev-ai

1 issue found and verified against the latest diff

Confidence score: 3/5

editor/src/messages/tool/common_functionality/gizmos/gizmo_manager.rs: mixed selections such as Star and Polygon are incorrectly grouped because Generic handlers all report kind() as "generic", risking incorrect gizmo handle behavior; make the grouping key distinguish the concrete shape type.

Prompt for AI agents (unresolved issues)


Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="editor/src/messages/tool/common_functionality/gizmos/gizmo_manager.rs">

<violation number="1" location="editor/src/messages/tool/common_functionality/gizmos/gizmo_manager.rs:35">
P1: When multiple shapes of different types are selected (e.g., Star and Polygon), all Generic handlers report the same `kind()` ("generic"), so the grouping logic incorrectly combines them. This causes one shape's handler to draw overlays for a different shape type, because `GenericGizmoManager::overlays` ignores the `selected_shape_layers` parameter and uses only the layer it was constructed with. Either track the actual shape type in `kind()` to prevent cross-shape grouping, or make `GenericGizmoManager` respect the layer parameter passed to `overlays`.</violation>
</file>

_{Reply with feedback, questions, or to request a fix.

Re-trigger cubic}

cubic-dev-ai

6 issues found across 28 files

Confidence score: 3/5

editor/src/messages/tool/common_functionality/gizmos/gizmo_manager.rs groups different selected shapes under the shared kind() value generic, so mixed selections such as stars and polygons can receive the wrong overlay rendering and altered grouping behavior in handle_actions — preserve distinct grouping identities for shapes or update the grouping logic.
editor/src/messages/tool/common_functionality/shapes/grid_shape.rs contains misleading panic messages in rect() and direction(), which can slow diagnosis when invalid grid data is encountered — correct the copied concept names.
The Generic enum documentation in editor/src/messages/tool/common_functionality/gizmos/gizmo_manager.rs is stale because migrated shapes including arcs, grids, spirals, and hearts now use it — update the documented variants to match the routing.
The registry length assertion in editor/src/messages/tool/common_functionality/gizmos/gizmo_registry.rs is coupled to the current node count, while check_if_over_gizmo in grid_shape.rs is unused and duplicates hit-testing logic elsewhere — assert specific registrations and remove or integrate the dead helper.

Prompt for AI agents (unresolved issues)


Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="editor/src/messages/tool/common_functionality/shapes/grid_shape.rs">

<violation number="1" location="editor/src/messages/tool/common_functionality/shapes/grid_shape.rs:196">
P3: `check_if_over_gizmo` is defined but never called anywhere in the crate. The grid gizmo's real hit-testing lives in `gizmo_behaviors.rs::grid_edge_distances`, which re-implements the same `rect().contains()` + `line().nearest()` proximity check, so this new function is dead code. Remove it (along with any helpers it alone uses) or wire it into the gizmo path.</violation>

<violation number="2" location="editor/src/messages/tool/common_functionality/shapes/grid_shape.rs:400">
P3: Four panic messages have copy-paste errors that name the wrong concept. In `rect()`, the message says "does not have opposite" instead of "does not have a rect". In `direction()`, it says "does not have a line" instead of "does not have a direction". In `initial_dimension()` and `spacing()`, both say "does not have a mouse_icon" when they should describe the method's actual return value. These misleading messages will confuse debugging if the panics are ever triggered.</violation>
</file>

<file name="editor/src/messages/tool/common_functionality/gizmos/gizmo_manager.rs">

<violation number="1" location="editor/src/messages/tool/common_functionality/gizmos/gizmo_manager.rs:19">
P3: The enum doc comment claims only "(polygon, circle, heart, star)" use the `Generic` variant, but this diff routes every shape (arc, grid, spiral, and the newly added heart) through `Generic`. The list is stale as of this change — the migration covered all seven shapes. Update the comment to reflect that all shape gizmos now go through `Generic`.</violation>

<violation number="2" location="editor/src/messages/tool/common_functionality/gizmos/gizmo_manager.rs:35">
P2: When multiple shapes of different types are selected (e.g., a star and a polygon), the grouping logic groups them together because all generic shapes return the same `kind()`. The overlay rendering then calls one shape's GenericGizmoManager to render overlays for a different shape's layer, which fails silently because GenericGizmoManager only contains gizmos for the layer it was created with. Either make GenericGizmoManager return a shape-specific kind ("generic-star", "generic-polygon", etc.) so different shapes remain in separate groups, or redesign the grouping to account for layer-specific handler instances.</violation>

<violation number="3" location="editor/src/messages/tool/common_functionality/gizmos/gizmo_manager.rs:35">
P2: Collapsing `kind()` to a single `"generic"` value for every migrated shape changes the grouping behavior in `handle_actions`. The `layers_handlers` grouping groups selected layers by `kind()`; previously each shape type had its own kind ("star", "polygon", ...), so a concurrently selected circle and star stayed in separate groups and each handler drew its own overlay. Now they share `"generic"` and are merged into one group, and since `GenericGizmoManager::overlays` ignores the `_selected_shape_layers` argument (it draws only its own bound node's gizmos), the first group's gizmo manager renders its gizmos once per layer in the merged group — showing circle gizmos on a star layer and duplicating overlays. This regresses multi-shape simultaneous-selection overlays versus the old per-kind grouping.</violation>
</file>

<file name="editor/src/messages/tool/common_functionality/gizmos/gizmo_registry.rs">

<violation number="1" location="editor/src/messages/tool/common_functionality/gizmos/gizmo_registry.rs:490">
P3: The test asserts a hardcoded `len() == 7`, but the registry is meant to grow as nodes are registered, so adding/removing a shape breaks this test for no behavioral reason. Assert against the specific expected node identifiers instead, so the test verifies content rather than an arbitrary count.</violation>
</file>

_{Reply with feedback, questions, or to request a fix.

Re-trigger cubic}

cubic-dev-ai

2 issues found across 12 files (changes from recent commits).

Confidence score: 3/5

In editor/src/messages/tool/common_functionality/gizmos/generic_gizmos/mod.rs, drawing a new circle can leave GizmoManager using cached handlers for the previous selection, causing the newly created layer to render incorrectly; preserve lazy selected-layer detection or refresh the handlers here.
In editor/src/messages/tool/common_functionality/gizmos/generic_gizmos/generic_slider_gizmo.rs, GizmoInfo::position_hint and PositionHint are now unused after their final runtime consumer was removed, leaving dead API/code that should be removed or intentionally restored.

Prompt for AI agents (unresolved issues)


Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="editor/src/messages/tool/common_functionality/gizmos/generic_gizmos/mod.rs">

<violation number="1" location="editor/src/messages/tool/common_functionality/gizmos/generic_gizmos/mod.rs:235">
P2: While drawing a new circle, `GizmoManager` does not refresh its cached handlers, so this method renders the previous selection instead of the newly created layer. Preserve selected-layer lazy detection here or refresh handlers when the drawing layer is created, otherwise the circle radius gizmo disappears during creation.</violation>
</file>

<file name="editor/src/messages/tool/common_functionality/gizmos/generic_gizmos/generic_slider_gizmo.rs">

<violation number="1" location="editor/src/messages/tool/common_functionality/gizmos/generic_gizmos/generic_slider_gizmo.rs:156">
P3: The `GizmoInfo::position_hint` field and the whole `PositionHint` enum are now never read by runtime code. This delta removed the last consumer: `GenericSliderGizmo::handle_positions` previously matched on `self.info.position_hint` (with both arms returning the same value), and it has collapsed to `None => vec![DVec2::new(value.abs(), 0.)]`. Every registry entry still writes `position_hint` (including `BoundingBoxCenter`/`BoundingBoxCorner`), but nothing ever reads it, so those hints are silently inert — a dead field that invites future nodes to set it expecting behavior that never happens.</violation>
</file>

_{Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic}

cubic-dev-ai · 2026-08-29T01:22:17Z

+		}
+	}
+
+	fn overlays(&self, document: &DocumentMessageHandler, _input: &InputPreprocessorMessageHandler, shape_editor: &mut &mut ShapeState, mouse_position: DVec2, overlay_context: &mut OverlayContext) {


P2: While drawing a new circle, GizmoManager does not refresh its cached handlers, so this method renders the previous selection instead of the newly created layer. Preserve selected-layer lazy detection here or refresh handlers when the drawing layer is created, otherwise the circle radius gizmo disappears during creation.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At editor/src/messages/tool/common_functionality/gizmos/generic_gizmos/mod.rs, line 235: <comment>While drawing a new circle, `GizmoManager` does not refresh its cached handlers, so this method renders the previous selection instead of the newly created layer. Preserve selected-layer lazy detection here or refresh handlers when the drawing layer is created, otherwise the circle radius gizmo disappears during creation.</comment> <file context> @@ -256,30 +232,7 @@ impl ShapeGizmoHandler for GenericGizmoManager { - return; - } - + fn overlays(&self, document: &DocumentMessageHandler, _input: &InputPreprocessorMessageHandler, shape_editor: &mut &mut ShapeState, mouse_position: DVec2, overlay_context: &mut OverlayContext) { for gizmo in &self.gizmos { gizmo.overlays(document, mouse_position, Some(shape_editor), overlay_context); </file context>

cubic-dev-ai · 2026-08-29T01:22:17Z

+	fn handle_positions(&self, document: &DocumentMessageHandler, value: f64) -> Vec<DVec2> {
+		match self.info.behavior.handle_positions {
+			Some(positions) => positions(&self.context(document, DVec2::ZERO, None), value),
+			None => vec![DVec2::new(value.abs(), 0.)],


P3: The GizmoInfo::position_hint field and the whole PositionHint enum are now never read by runtime code. This delta removed the last consumer: GenericSliderGizmo::handle_positions previously matched on self.info.position_hint (with both arms returning the same value), and it has collapsed to None => vec![DVec2::new(value.abs(), 0.)]. Every registry entry still writes position_hint (including BoundingBoxCenter/BoundingBoxCorner), but nothing ever reads it, so those hints are silently inert — a dead field that invites future nodes to set it expecting behavior that never happens.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At editor/src/messages/tool/common_functionality/gizmos/generic_gizmos/generic_slider_gizmo.rs, line 156: <comment>The `GizmoInfo::position_hint` field and the whole `PositionHint` enum are now never read by runtime code. This delta removed the last consumer: `GenericSliderGizmo::handle_positions` previously matched on `self.info.position_hint` (with both arms returning the same value), and it has collapsed to `None => vec![DVec2::new(value.abs(), 0.)]`. Every registry entry still writes `position_hint` (including `BoundingBoxCenter`/`BoundingBoxCorner`), but nothing ever reads it, so those hints are silently inert — a dead field that invites future nodes to set it expecting behavior that never happens.</comment> <file context> @@ -151,18 +147,13 @@ impl GenericSliderGizmo { - // hints are refined as more node types adopt the slider. - _ => DVec2::new(value.abs(), 0.), - }], + None => vec![DVec2::new(value.abs(), 0.)], } } </file context>

cubic-dev-ai

1 issue found across 12 files (changes from recent commits).

Confidence score: 5/5

In editor/src/messages/tool/common_functionality/gizmos/generic_gizmos/generic_slider_gizmo.rs, a comment still refers to removed PositionHint/position_hint behavior, which could mislead future maintenance but does not indicate a functional regression — update or remove the stale comment.

Prompt for AI agents (unresolved issues)


Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="editor/src/messages/tool/common_functionality/gizmos/generic_gizmos/generic_slider_gizmo.rs">

<violation number="1" location="editor/src/messages/tool/common_functionality/gizmos/generic_gizmos/generic_slider_gizmo.rs:151">
P3: This comment still describes "bounding-box position hints" falling through to the default handle, but `PositionHint`/`position_hint` was dropped entirely in this PR (commit "Drop the position hint"), and the `handle_positions` `None` branch no longer consults any hint. The comment now points readers at a mechanism that no longer exists. Drop the trailing sentence and just document that the default single handle sits `value` out along the local +X axis.</violation>
</file>

_{Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic}

cubic-dev-ai · 2026-08-29T01:33:14Z

+	/// Every point in the layer's local space where this parameter can be grabbed.
+	///
+	/// A shape that puts its handles on its own geometry supplies them. Everything else gets the single
+	/// default handle, `value` out along the local +X axis. The bounding-box position hints fall


P3: This comment still describes "bounding-box position hints" falling through to the default handle, but PositionHint/position_hint was dropped entirely in this PR (commit "Drop the position hint"), and the handle_positions None branch no longer consults any hint. The comment now points readers at a mechanism that no longer exists. Drop the trailing sentence and just document that the default single handle sits value out along the local +X axis.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At editor/src/messages/tool/common_functionality/gizmos/generic_gizmos/generic_slider_gizmo.rs, line 151: <comment>This comment still describes "bounding-box position hints" falling through to the default handle, but `PositionHint`/`position_hint` was dropped entirely in this PR (commit "Drop the position hint"), and the `handle_positions` `None` branch no longer consults any hint. The comment now points readers at a mechanism that no longer exists. Drop the trailing sentence and just document that the default single handle sits `value` out along the local +X axis.</comment> <file context> @@ -151,18 +147,13 @@ impl GenericSliderGizmo { - /// Shapes that place their handles on their own geometry supply them; everything else gets the single - /// default handle, sitting `value` out along the local +X axis. + /// A shape that puts its handles on its own geometry supplies them. Everything else gets the single + /// default handle, `value` out along the local +X axis. The bounding-box position hints fall + /// through to that same default until a node needs them. fn handle_positions(&self, document: &DocumentMessageHandler, value: f64) -> Vec<DVec2> { </file context>

Every shape declares its gizmos in the registry now, so the seven per-shape branches in `detect_shape_handler` all returned the same thing, and `ShapeGizmoHandlers` wrapped a single variant. Its `kind()` grouping collapsed into one bucket, which is why overlays re-detected a layer's gizmos every frame; holding one handler per layer drops that. The grid's `RowColumnGizmoType::None` had no construction site and eight panicking accessors, four with another method's message. Delete it along with `check_if_over_gizmo`, `opposite_gizmo_type`, `mouse_icon` and `all()`, which were dead with it. Fix a doc comment sitting on the wrong function, a match whose two arms were identical, a link to a file that does not exist, and a README snippet with the wrong signature. Give the `GizmoBehavior` constants a `..NONE` tail so each shows only what is unusual about it.

Every declaration set `position_hint` and nothing read it: the only match on it returned the same expression from both arms, so the bounding-box variants never anchored anything. Shapes that need a handle elsewhere already use `handle_positions`. Also replace the registry test's `len() == 7` assertion, which checks the length of a fixed-size array and so cannot fail, with the seven identifiers it meant to check.

The layer being dragged out is created after the last `handle_actions` pass, which only runs while the tool is ready, so the overlay drawn during a circle drag showed the previous selection.

cubic-dev-ai

2 issues found across 12 files (changes from recent commits).

Confidence score: 3/5

In editor/src/messages/tool/tool_messages/shape_tool.rs, Circle drawing can rebuild an inactive handler without running hover arbitration, causing circular_radius_overlay to render nothing; run the handler state pass before rendering.
In editor/src/messages/tool/common_functionality/gizmos/gizmo_manager.rs, refresh_handlers can leave a stale active handler rendering while the refreshed selection is skipped, producing incorrect gizmo overlays; clear active_shape_handler before rebuilding or re-arbitrate afterward.

Prompt for AI agents (unresolved issues)


Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="editor/src/messages/tool/tool_messages/shape_tool.rs">

<violation number="1" location="editor/src/messages/tool/tool_messages/shape_tool.rs:954">
P2: While drawing a Circle, this rebuilds an inactive handler but never runs hover arbitration, so `circular_radius_overlay` returns without drawing anything. Run the handler state pass before rendering so the new Circle handler can become hovered and display its radius overlay.</violation>
</file>

<file name="editor/src/messages/tool/common_functionality/gizmos/gizmo_manager.rs">

<violation number="1" location="editor/src/messages/tool/common_functionality/gizmos/gizmo_manager.rs:32">
P2: When `refresh_handlers` runs with an existing active handler, `overlays` continues rendering that stale handler and skips the refreshed selection. Clear `active_shape_handler` when rebuilding handlers, or re-arbitrate it against the new selection.</violation>
</file>

_{Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic}

cubic-dev-ai · 2026-08-29T01:46:28Z

 					if tool_options.shape_type == ShapeType::Circle {
+						// The layer being dragged out was created after the last `handle_actions` pass, which only
+						// runs while the tool is ready, so its handler has to be built here.
+						tool_data.gizmo_manager.refresh_handlers(document);


P2: While drawing a Circle, this rebuilds an inactive handler but never runs hover arbitration, so circular_radius_overlay returns without drawing anything. Run the handler state pass before rendering so the new Circle handler can become hovered and display its radius overlay.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At editor/src/messages/tool/tool_messages/shape_tool.rs, line 954: <comment>While drawing a Circle, this rebuilds an inactive handler but never runs hover arbitration, so `circular_radius_overlay` returns without drawing anything. Run the handler state pass before rendering so the new Circle handler can become hovered and display its radius overlay.</comment> <file context> @@ -953,6 +949,9 @@ impl Fsm for ShapeToolFsmState { if tool_options.shape_type == ShapeType::Circle { + // The layer being dragged out was created after the last `handle_actions` pass, which only + // runs while the tool is ready, so its handler has to be built here. + tool_data.gizmo_manager.refresh_handlers(document); tool_data.gizmo_manager.overlays(document, input, shape_editor, mouse_position, &mut overlay_context); } </file context>

cubic-dev-ai · 2026-08-29T01:46:28Z

+	/// [`handle_actions`](Self::handle_actions) does this as part of its pass. A caller that draws overlays
+	/// from a state where it does not run, such as while a shape is still being dragged out, has to ask for
+	/// it here or it draws the previous selection.
+	pub fn refresh_handlers(&mut self, document: &DocumentMessageHandler) {


P2: When refresh_handlers runs with an existing active handler, overlays continues rendering that stale handler and skips the refreshed selection. Clear active_shape_handler when rebuilding handlers, or re-arbitrate it against the new selection.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At editor/src/messages/tool/common_functionality/gizmos/gizmo_manager.rs, line 32: <comment>When `refresh_handlers` runs with an existing active handler, `overlays` continues rendering that stale handler and skips the refreshed selection. Clear `active_shape_handler` when rebuilding handlers, or re-arbitrate it against the new selection.</comment> <file context> @@ -1,212 +1,58 @@ + /// [`handle_actions`](Self::handle_actions) does this as part of its pass. A caller that draws overlays + /// from a state where it does not run, such as while a shape is still being dragged out, has to ask for + /// it here or it draws the previous selection. + pub fn refresh_handlers(&mut self, document: &DocumentMessageHandler) { + self.layer_handlers = document + .network_interface </file context>

Suggested change

pub fn refresh_handlers(&mut self, document: &DocumentMessageHandler) {

pub fn refresh_handlers(&mut self, document: &DocumentMessageHandler) {

self.active_shape_handler = None;

Keavon and others added 28 commits August 26, 2026 07:21

Heart node

ca6bbe6

Add Heart drawing mode to the Shape tool with gizmo registration

bfcb4ca

Migrate the Heart node to the ranked node input API

f1b203d

Add registry-driven generic gizmo system

48796d5

Migrate the Circle gizmo to the generic registry system

19a79e1

Migrate the Polygon gizmo to the generic registry system

52f02bf

Add the Heart's radius gizmo via the generic registry system

fc87ae9

Port the gizmo registry stack to current master's geometry and parame…

8ab60ba

…ter APIs

Cover the ported heart geometry with tests

c97ca64

Give the generic gizmos an escape hatch for shape-specific behavior

e479206

Restore the polygon dial's spokes and outline, lost in the generic mi…

0069cba

…gration

Migrate the Star gizmos to the generic registry system

b891871

Migrate the Spiral gizmo to the generic registry system

fae76a9

Migrate the Arc gizmos to the generic registry system

e8edf73

Migrate the Grid gizmos to the generic registry system

1d76a3b

Name the gizmo hook signatures

ba5a89b

Restore the circumference grab for circle and arc radii, and stop the…

9d865b7

… grid drawing a stray handle

Match the sides dial to the one it replaced

24fa18c

Show a resting handle for gizmos that draw nothing of their own

cf3db70

Give the polygon back its radius handles

2b0ffd2

Put handles on the heart's cleavage and shoulders

cc2c623

Measure a gizmo drag from where it started, not from where the cursor is

190d2ef

Read a circular radius drag horizontally, from wherever it was grabbed

0bb008c

Write the guide for adding a gizmo to a node

44ae618

Rank a point handle above a region handle when the two overlap

209be12

Correct the stale comment on the polygon gizmo declarations

e830897

Draw the heart in document units and skip degenerate drags

ad3dff3

Describe the cleavage angle correctly and test symmetry against the c…

9b493fe

…urve

Ayush2k02 marked this pull request as ready for review August 26, 2026 18:01

Scope the ParamCurve import to the tests that use it

d0e3fdc

cubic-dev-ai Bot reviewed Aug 26, 2026

View reviewed changes

Ayush2k02 added 8 commits August 27, 2026 00:37

Draw the heart through the shared window-aligned transform helper

745e688

Resolve overlays against the layer the manager is given

53f9dd5

Stop defaulting the grid gizmo type into its panicking variant

3cb1c28

Clamp the dial to the parameter's own type and the slider after snapping

3523690

Guard the star's reciprocal snap radius against a near-zero factor

0a2a89c

Re-sync the control bar when a gizmo drag ends

5709968

Look up a registry entry without allocating

9686ca1

Resolve the circular radius parameter in one lookup

f0e2b5b

cubic-dev-ai Bot reviewed Aug 29, 2026

View reviewed changes

Ayush2k02 added 3 commits August 29, 2026 07:08

Refresh the gizmo handlers while a shape is being drawn

65119e7

The layer being dragged out is created after the last `handle_actions` pass, which only runs while the tool is ready, so the overlay drawn during a circle drag showed the previous selection.

Ayush2k02 force-pushed the gizmo/registry-system branch from 70af8df to 65119e7 Compare August 29, 2026 01:38

cubic-dev-ai Bot reviewed Aug 29, 2026

View reviewed changes

	pub fn refresh_handlers(&mut self, document: &DocumentMessageHandler) {
	pub fn refresh_handlers(&mut self, document: &DocumentMessageHandler) {
	self.active_shape_handler = None;

Uh oh!

Uh oh!

Conversation

Ayush2k02 commented Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cubic-dev-ai Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cubic-dev-ai Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Aug 29, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Aug 29, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Aug 29, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Aug 29, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Aug 29, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Ayush2k02 commented Aug 26, 2026 •

edited

Loading

cubic-dev-ai Bot left a comment •

edited

Loading

cubic-dev-ai Bot left a comment •

edited

Loading