godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.12k stars 76 forks source link

Export `EditorInspector::instantiate_property_editor` for plugin development in the Godot API #8908

Open limbonaut opened 8 months ago

limbonaut commented 8 months ago

Describe the project you are working on

LimboAI behavior trees & state machines (C++ module and extension) https://github.com/limbonaut/limboai

Describe the problem or limitation you are having in your project

We have a custom EditorProperty that adds additional UI controls and reuses existing property editors. It uses editors declared in editor_properties.h and other files to edit a value of a behavior tree parameter and adds additional functionality like an ability to bind the edited property to a blackboard variable. Currently, I don't see a way how we can have the same functionality in GDExtension version unless we reimplement every property editor in the core.

Here is a short demonstration video:

https://github.com/godotengine/godot-proposals/assets/2766569/9cd48481-4d51-4115-9303-0f12a87df1f7

I could also use instantiate_property_editor to implement a custom blackboard editor with a better experience than editing a Dictionary property.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Expose EditorInspector::instantiate_property_editor in the Godot API, so that plugin developers could reuse existing property editors in their projects.

Currently, instantiate_property_editor is used by the following classes in the core:

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

var editor: EditorProperty = EditorInterface.get_inspector().instantiate_property_editor(...)
# Do whatever you want with this property editor ...

If this enhancement will not be used often, can it be worked around with a few lines of script?

Very hard to achieve, considering that other custom property editors can be registered by various plugins. We could reimplement every property editor that exists in the core...

Is there a reason why this should be core and not an add-on in the asset library?

It is already in the core. Reimplementing property editors would only lead to repetition and fragmentation.

RedMser commented 8 months ago

This is also mentioned in #300 which also points out that all EditorProperty subclasses should be exposed as well (not sure if they have to be exposed in order to work properly in GDScript, but it would make sense).

limbonaut commented 8 months ago

Do you really need to export all the editors for this to work?

I've tested briefly with a small patch like this added to the EditorInspector code:

ClassDB::bind_static_method("EditorInspector", D_METHOD("instantiate_property_editor", "object", "type", "path", "hint", "hint_text", "usage", "wide"), &EditorInspector::instantiate_property_editor);

And it works. Was able to create a multiline editor for a string property in GDScript:

<EditorPropertyMultilineText#3420538863012>
blackears commented 8 months ago

I would like to see all the editors individually because it could be useful to use them independently of the EditorInspector container. Ie, just drop them anywhere into your scene the way you can with a LineEdit or Button.