Export EditorInspector::instantiate_property_editor for plugin development in the Godot API

[limbonaut]

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:

limboai_param_custom_editor.mp4

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:

• VisualShaderEditor
• AnimationNodeBlendTreeEditor
• EditorPropertyArray

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]

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]

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]

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.