Fix text layer getting deselected after clicking out of Text tool interactive editing

[Sidharth-Singh10]

Closes #2127

• Introduced the active_panel field in DocumentMessageHandler to track the currently active interface panel.
• Added a match expression in set_editing fn to verify if the active panel is the Properties Panel, preventing its deselection during edits.

Screencast_20241218_015818.online-video-cutter.com.mp4

[0HyperCube]

Works well; thanks for this contribution.

[Keavon]

@adamgerhant could you please review this in regards to the introduced ActivePanel code, to make sure it doesn't conflict with your existing implementation of the related concept of the active panel used for showing whether the graph's subnetwork or Layers panel is active?

[adamgerhant]

The active panel is currently being stored in the portfolio message handler. There is no need to store it in the document message handler.

[0HyperCube]

@adamgerhant the text tool code can't access the portfolio message handler.

[adamgerhant]

Why not just leave the text layer as selected when editing ends?

[Sidharth-Singh10]

I haven't worked much with design tools much, but doesn't keeping text layers selected after editing deviates from standard design tool patterns where edits typically end in deselection.
Persistent selection might create risk for accidental modifications - users may unintentionally resize/move/style the text layer when they meant to work on something else.

In this implementation the layer while in editing is deselected when clicked anywhere else expect properties panel

[Keavon]

@Sidharth-Singh10 I like where you're going with that thought process, although I believe for consistency with other drawing tools in Graphite, it would be best to keep it selected after clicking out. If you draw with any other tool like Rectangle or Ellipse, you'll notice if you look in the Layers panel, that layer remains selected after finishing drawing it. So it'd be best if the layer remains selected if you click anywhere in the viewport, or anywhere else in the UI, after interactively editing the text. Thanks :)

[Keavon]

See my previous comment for the updated approach, thanks!

[Keavon]

!build

[github-actions]

📦 Build Complete for 2d77dcb
https://3a16e2da.graphite.pages.dev

[Keavon]

Can I have you add another little improvement to this PR while I'm thinking about it? If the user is editing the interactive text in the viewport, and hits escape, it should delete the entire text layer if escape was pressed when the text was empty. So if a user creates text in the wrong spot but doesn't type anything (or types then deletes it all), escape will delete the layer so it doesn't get invisibly stuck behind. In addition to the escape key, also right clicking somewhere outside the text within the viewport should have the same effect as escape.

[Keavon]

!build

[github-actions]

📦 Build Complete for 6ecc336
https://94cb21e2.graphite.pages.dev

[Keavon]

!build

[Keavon]

It looks like Escape is working but right-click isn't for canceling an empty text layer for it to get deleted. Can you please look into making it work when it's empty and the user right-clicks?

(Also note that I rebased, so you'll need to pull before continuing to code on it.)

[github-actions]

📦 Build Complete for 60901c0
https://a8ca4611.graphite.pages.dev

[Sidharth-Singh10]

Hey @Keavon, I added an entry for MouseRight with action_dispatch set to TextToolMessage::CommitText in input_mapping.rs, but it doesn't seem to have any effect.

To confirm I was editing the correct location, I commented out the MouseLeft entry with action_dispatch set to TextToolMessage::Interact. This prevented placing or editing text, which suggests my changes are indeed in the right place.

Could you nudge me in the right direction?

[Keavon]

I'll ping @0HyperCube to see if he can answer your question about that.

[0HyperCube]

@Sidharth-Singh10

The actions that are advertised to the input mapper system don't include the commit text when the text is not being edited:

fn actions(&self) -> ActionList {
	match self.fsm_state {
		TextToolFsmState::Ready => actions!(TextToolMessageDiscriminant;
			Interact,
		),
		TextToolFsmState::Editing => actions!(TextToolMessageDiscriminant;
			Interact,
			Abort,
			CommitText,
		),
	}
}

Any time any mouse button is pressed that is not inside the text input, input.ts:175 sends editor.handle.onChangeText which sets editing to false.

[Sidharth-Singh10]

Thanks for pointing this out!

[Keavon]

!build

[github-actions]

📦 Build Complete for a29a3a8
https://dbab0636.graphite.pages.dev

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (2)

editor/src/messages/tool/tool_messages/text_tool.rs:257

• The check for has_remove_textbox should be done before adding DisplayRemoveEditableTextbox to the responses to avoid redundancy.

let has_remove_textbox = responses.iter().any(|msg| matches!(msg, Message::Frontend(FrontendMessage::DisplayRemoveEditableTextbox)));

editor/src/messages/tool/tool_messages/text_tool.rs:467

• The set_editing call should be made after deleting the empty text layer to prevent potential UI issues.

tool_data.set_editing(false, font_cache, responses);

[Keavon]

@Sidharth-Singh10 your solution to emulate an escape keypress from the frontend TS code is a hack that works but isn't very clean. Can you please take into account what Hypercube wrote and implement a solution in the backend Rust code? In other words, you need to have something run before the tool state leaves Editing and returns to Ready to check if that TS code he mentioned is causing it to return to Ready.

[Keavon]

!build

[github-actions]

📦 Build Complete for 2686957
https://bcbcd48f.graphite.pages.dev