Open Zylann opened 1 year ago
Exposing EditorInspector
so you can use it in editor plugins is definitely on my radar, btw.
This issue definitely needs more traction. As Godot is primarily community driven, it's important to provide contributors with tools to extend it's functionality. It's unfortunate that the author of HTerrain had to implement what is essentially already a part of core engine, just not exposed yet for some reason.
@elthundercloud Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.
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?
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.
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.
There could be several workarounds:
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
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?
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.
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:
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 toEditorInspector
, 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:
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 betweenEditorResourceProperty
andEditorResourcePicker
... 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.