Skip to content

Make path editable for grouped graphic inputs#3901

Open
krVatsal wants to merge 7 commits intoGraphiteEditor:masterfrom
krVatsal:Make-Path-Editable
Open

Make path editable for grouped graphic inputs#3901
krVatsal wants to merge 7 commits intoGraphiteEditor:masterfrom
krVatsal:Make-Path-Editable

Conversation

@krVatsal
Copy link
Contributor

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
Copy link
Contributor

Summary of Changes

Hello, I'm Gemini Code Assist1! 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.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

(_, 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<_>>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants