Allow contextual plugins to persist temporarily

[KoBeWi]

Fixes #72271

This makes the theme editor semi-persistent. If you edit a theme from the FileSystem Dock or directly in the inspector (via Edit), the editor will not be closed when something else takes over its editing context. A close button was added to close the editor manually.
The editor can still close automatically if its editing context vanishes (EditorProperty).

godot.windows.editor.dev.x86_64_vO8cL5OzT1.mp4

[YuriSizov]

That's a neat trick, and I think we could do this. But the case of editing a theme attached to a control is still important, I believe, and this trick doesn't cover that case. So I wouldn't say it fully closes the issue.

There's also a bug:

editor\editor_node.cpp:8087 - Condition "plugins_list.has(p_plugin)" is true.

godot.windows.editor.dev.x86_64_2023-09-11_14-25-14.mp4

[KoBeWi]

The bug is fixed.

But the case of editing a theme attached to a control is still important, I believe, and this trick doesn't cover that case.

The Theme Editor is closed, because the EditorProperty that was editing the theme is gone. I could make it persist, but then deselecting the node would keep the theme edited. Not sure if that's desirable.

[YuriSizov]

Could we add the old hack to can_auto_hide which checked if the edited object is also a stylebox, a font, or a texture that the edited theme holds?

[KoBeWi]

Done, but I had to do a questionable change. Inspector sets new object before clearing, so that plugins can know it before being cleared.

[YuriSizov]

Going back in history is a font of all sorts of bugs 🙁 Closing the theme normally seems to work fine. But once you close it under the conditions demonstrated in the clip, you can no longer open the theme edit:

godot.windows.editor.dev.x86_64_2023-09-14_20-42-26.mp4

Regarding the unnatural thing that you had to do, it's probably fine. But to be absolutely safe you could add get_next_edited_object() or something like that? That's all you need from the hack, to be able to get a reference through the inspector dock to the upcoming edited object.

[YuriSizov]

@KoBeWi Any news on fixing the bug (and maybe doing the pre-edit step in a less nasty manner)?

[KoBeWi]

I will finish this one day.

[YuriSizov]

I'll put it into draft for now, feel free to undraft once it's ready

[KoBeWi]

Ok I fixed the history bug. I just forgot to unref Theme when closing the editor.
Also added get_next_edited_object() like you suggested.

[YuriSizov]

As described on RC, there is currently an issue because behavior is different between the main inspector and sub inspectors. For subinspectors get_next_edited_object() doesn't work, because it gets cleared before we get to the theme editor, so it has nothing to work with. For subinspectors using the old get_edited_object() method is sufficient. But it works the other way around for the main inspector.

The solution can be as simple as moving the clearing step to the last possible moment:

diff --git a/editor/editor_inspector.cpp b/editor/editor_inspector.cpp
index 5985bdf525..233fcd10ce 100644
--- a/editor/editor_inspector.cpp
+++ b/editor/editor_inspector.cpp
@@ -3408,7 +3408,6 @@ void EditorInspector::edit(Object *p_object) {
 	per_array_page.clear();
 
 	object = p_object;
-	next_object = nullptr;
 
 	if (object) {
 		update_scroll_request = 0; //reset
@@ -3418,6 +3417,10 @@ void EditorInspector::edit(Object *p_object) {
 		object->connect("property_list_changed", callable_mp(this, &EditorInspector::_changed_callback));
 		update_tree();
 	}
+
+	// Keep it available until the end so it works with both main and sub inspectors.
+	next_object = nullptr;
+
 	emit_signal(SNAME("edited_object_changed"));
 }

---

However, you can still manage to permanently disable the theme editor with this PR. Open a theme resource, then edit its subresource. Use the inspector history to navigate back to the theme and close the editor. You will no longer be able to open it by any means.

godot.windows.editor.dev.x86_64_2023-10-06_15-23-39.mp4

This does NOT happen if you open a control that has a theme as a subresource. Doing similar steps still restores the theme editor.

[KoBeWi]

Fixed. Theme editor was clearing the inspector to remove itself, but the code for hiding editors did not handle self-owning plugins.

[YuriSizov]

I tried a few more things and couldn't kill it anymore. I declare this a success!

[akien-mga]

Thanks!