Allow to create Editor Inspectors (for plugin UIs)

[Zylann]

Describe the project you are working on

Plugins and extensions.

Describe the problem or limitation you are having in your project

Quite often when developing complex plugins, I end up needing to create a UI with series of properties to edit, often mapping to an object. But each time, I have to either code and setup each editor by hand, or make my own inspector-like controls. This is fine if there are only a handful of properties, but becomes a hassle with more complex objects.
There is only one "inspector" plugins can currently exploit, and it is the one in the "inspector dock".

My specific needs are:

• I have editors separate from the inspector, and they need property-editing functionality without having to "replace" whatever object is in the inspector dock.
• I have some things to edit in a resource that cannot be name/value properties, therefore I use a custom control that I insert with an inspector plugin, but inside that control I need to put sub-inspectors for sub-resources, which is not possible without obliterating whatever is inspected in the dock. This notably leads me to drop entirely the inspector and make a separate editor from scratch, which has to somehow delegate editing sub-resources to the inspector in parallel.

But I'm sure other situations exist, like shown in usages in core.

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

From what I could understand, EditorInspector is a control used for the inspector dock, sub-inspector, project settings, tilemap editor, and every other place that needs to edit an object like a property sheet.
The idea is to expose its functions and allow creating instances of it, setting which object it inspects, and also optionally hook up UndoRedo, since everything in the editor should be undoable, both for good UX and proper saving of modified resources.
EditoInspectorPlugins would also be functional, so it doesnt matter much where you edit a resource, it doesnt have to be the inspector dock (though it could be turned off if not desired).

The class is currently exposed, but only to allow plugins to hook signals, it has no other API (was initially exposed for the instance in the inspector dock obtained from EditorInterface).
Also, there is an incentive recently to make some editor classes singletons in the script API, but this should not apply to EditorInspector, because otherwise it would really prevent from making it instantiable and re-usable.

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

There are examples of usage already in the Godot codebase:

• TileSetAtlasSourceEditor https://github.com/godotengine/godot/blob/543750a1b3f5696f9ba8e91cb49dc7db05d2ae62/editor/plugins/tiles/tile_set_atlas_source_editor.cpp#L2533
• Sub inspectors themselves: https://github.com/godotengine/godot/blob/543750a1b3f5696f9ba8e91cb49dc7db05d2ae62/editor/editor_properties.cpp#L3309
• ShaderGlobalsEditor: https://github.com/godotengine/godot/blob/543750a1b3f5696f9ba8e91cb49dc7db05d2ae62/editor/shader_globals_editor.cpp#LL482C38-L482C38
• And more

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

No. It needs a LOT of lines of script: https://github.com/Zylann/godot_heightmap_plugin/blob/master/addons/zylann.hterrain/tools/inspector/inspector.gd
And is nowhere near the amount of functionalities and integration provided by EditorInspector.

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

It is already core, just not exposed properly. Maybe it only needs some cleanup. It also integrates deeper than a plugin could.

Although, exposing it alone wouldn't be enough for plugins to make sub-inspectors, as from what I see in EditorPropertyResource, a bunch of extra logic is done when editing resource properties, not just creating an inspector, which I am not familiar with. Maybe it needs to have somehow a middle-ground between EditorResourceProperty and EditorResourcePicker... can't be an InspectorProperty if it's not an actual property of an object, but has to be something that allows editing a resource inside a UI that shows it as a "value" field.

[me2beats]

see also
#1761
#1761
#123

[YuriSizov]

Exposing EditorInspector so you can use it in editor plugins is definitely on my radar, btw.

[Calinou]

@elthundercloud Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead.

[API-Beast]

A good first step would be to at least expose the EditorProperty subclasses defined in editor_properties.h. This would make writing your own inspector already much easier, even if you can't instance the builtin EditorInspector.

EditorInspector is already exposed, but unfortunately in a very incomplete way, only exposing it's signals and almost none of it's functions and none of it's properties. I assume this is because it has significant coupling with the rest of the engine?

[Difint]

Highly support the initiative.

Editor has a lot of great Control and it would be great to expose them.

That would not only help to create games, but also more complex software as a lot of Editor Widgets implements highly needed things.

[Calinou]

That would not only help to create games, but also more complex software as a lot of Editor Widgets implements highly needed things.

Exposing editor nodes to the plugin API won't make it possible to use editor docks in exported projects, as the code isn't included in export templates for binary size reasons.

[Difint]

There could be several workarounds:

1. A special build that includes all or most of the EditorNodes
2. Create a bunch of plugins based on Editor Code and GDExtensions

For me personally the most needed and interesting missing component is Inspector.

I've taken a brief look at the code and in looks like Inspector inherits from Control node and internally has no reference to Editor specific features, thou I'm not sure yet.

I'll take a deeper look at the second option - exposing Editor features via GDExtension, will share the results

[SirLich]

Hi! I'm currently doing some work in @tool scripts, and I'm running into the issue that inspector types (e.g., EditorPropertyCheck) are not exposed to GDScript.

This ... somewhat makes sense, but I'm wondering whether exposing these for usage inside @tool scripts would be possible? I mean without large scale changes to the structure.

My thinking is that tool scripts are intended to run in the editor, so it doesn't seems like a no brainer that they would have access to these editor types.

Related question: if I WERE to move to GDExtension, would C++ code somehow have deeper access into these types, or is it blocked by the binding code, rather than it being GDScript itself?

[limbonaut]

Hi! I'm currently doing some work in @tool scripts, and I'm running into the issue that inspector types (e.g., EditorPropertyCheck) are not exposed to GDScript.

This ... somewhat makes sense, but I'm wondering whether exposing these for usage inside @tool scripts would be possible? I mean without large scale changes to the structure.

My thinking is that tool scripts are intended to run in the editor, so it doesn't seems like a no brainer that they would have access to these editor types.

Related question: if I WERE to move to GDExtension, would C++ code somehow have deeper access into these types, or is it blocked by the binding code, rather than it being GDScript itself?

godot-cpp doesn't have access to EditorProperty* types. The access level is almost identical to GDScript, in fact.