Open limbonaut opened 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).
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>
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.
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 ineditor_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 aDictionary
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
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.