Make path editable for grouped graphic inputs

[krVatsal]

Continues work from #3735 since @jsjgdh cannot continue.

Refactors path editability checks into a shared helper and applies it consistently in both menu eligibility and Path Tool selection handling. This enables grouped layers [Table<Graphic>] to be treated as path editable while preserving existing behavior for vector inputs.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the Path Tool's capabilities by allowing direct path editing for grouped graphic inputs. It achieves this by centralizing and refining the logic for determining path editability, ensuring that both menu eligibility and the Path Tool's selection process consistently recognize and handle these new editable layer types. This change improves the user experience by providing more flexible and intuitive interaction with complex graphic compositions.

Highlights

• Refactored Path Editability Logic: The logic for determining if a layer's path is editable has been refactored into a new shared helper function, layer_can_be_path_editable_input, promoting consistency across different parts of the editor.
• Enabled Path Editing for Grouped Graphics: Path editability has been extended to include grouped graphic layers (Table<Graphic>), allowing users to directly edit paths within these groups, in addition to existing vector inputs (Table<Vector>).
• Updated Path Tool Selection: The Path Tool's selection handling has been updated to correctly identify and target path-editable layers, including the ability to 'drill down' into grouped layers to select individual path-editable children.

Changelog

• editor/src/messages/tool/common_functionality/utility_functions.rs
  • Imported Graphic type for new path editability checks.
  • Refactored make_path_editable_is_allowed to utilize the new layer_can_be_path_editable_input helper function.
  • Added layer_can_be_path_editable_input function to determine if a layer's input is Table<Vector> or Table<Graphic>.
• editor/src/messages/tool/tool_messages/path_tool.rs
  • Imported the new layer_can_be_path_editable_input helper function.
  • Modified the SelectionChanged event handler to iterate through selected layers, checking for path editability and expanding grouped layers to include their path-editable children in the selection.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors path editability checks to support grouped graphic inputs, which is a great improvement. The new helper function layer_can_be_path_editable_input correctly identifies Table<Graphic> as editable. I've found a potential issue in the PathTool's selection handling logic where a non-path-editable layer without children is kept in the list of targets. I've suggested a fix to remove such layers, which also simplifies the code.

[cubic-dev-ai]

1 issue found across 2 files

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/path_tool.rs">

<violation number="1" location="editor/src/messages/tool/tool_messages/path_tool.rs:1581">
P1: New descendant-expansion selection logic desynchronizes `shape_editor` layer targeting from document-selected nodes, but later edits still resolve layer from document selection, causing wrong-layer operations or aborted actions.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P1: New descendant-expansion selection logic desynchronizes shape_editor layer targeting from document-selected nodes, but later edits still resolve layer from document selection, causing wrong-layer operations or aborted actions.

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/path_tool.rs, line 1581:

<comment>New descendant-expansion selection logic desynchronizes `shape_editor` layer targeting from document-selected nodes, but later edits still resolve layer from document selection, causing wrong-layer operations or aborted actions.</comment>

<file context>
@@ -1578,7 +1578,26 @@ impl Fsm for PathToolFsmState {
 			(_, PathToolMessage::SelectionChanged) => {
 				// Set the newly targeted layers to visible
-				let target_layers = document.network_interface.selected_nodes().selected_layers(document.metadata()).collect();
+				let mut target_layers = document.network_interface.selected_nodes().selected_layers(document.metadata()).collect::<Vec<_>>();
+
+				let mut i = 0;
</file context>

[krVatsal]

Just a doubt @Keavon @jsjgdh, the current fix makes it behave as you told but a slight diversion is here. Asking just to confirm if the current behaviour looks good or should i make exactly as you told.
The current behavior is that when you select a grouped layer using path tool then the button can be seen active(as you told) but the vectors aren't getting auto-selected, so when we click on any one of the shape(without clicking on make path editable) then we will be only modifying that vector and not entire group. Further when we click on make path editable then we get both the path and flatten path nodes as expected.

Recording.2026-03-17.100620.1.mp4

[jsjgdh]

Just a doubt @Keavon @jsjgdh, the current fix makes it behave as you told but a slight diversion is here. Asking just to confirm if the current behaviour looks good or should i make exactly as you told. The current behavior is that when you select a grouped layer using path tool then the button can be seen active(as you told) but the vectors aren't getting auto-selected, so when we click on any one of the shape(without clicking on make path editable) then we will be only modifying that vector and not entire group. Further when we click on make path editable then we get both the path and flatten path nodes as expected.

Recording.2026-03-17.100620.1.mp4

@Keavon will be the only one who will be able to answer this question .