Expose more classes and functionality to editor plugins

[samdze]

Describe the project you are working on:

Editor plugins that use inspector plugins, reflection and that create dynamic properties.
See: https://github.com/samdze/godot-modifiers-plugin

Describe the problem or limitation you are having in your project:

During the development of the plugin I ran into many limitations, Godot often just didn't expose the methods and the classes I needed to efficiently create the plugin.
This would be more like a tracker of all the stumblings I came across.
Here's a list of things I'd like to see added or addressed, some of which I'm not sure if already available or not:

• 1. Expose all editor types, at least those useful to create plugins, like the subclasses of EditorProperty, various dialogs/containers (to select a property from a node or resource, to select a method, to create a Node/Resource, ecc). Also in the Create Dialog, maybe hidden by default and displayed only if explicitly selected in a dropdown menu. (like in the Search Help dialog)
• 2. Expose EditorInspector:instantiate_property_editor, or a method that does the following, users can automatically instantiate the right EditorProperty (based on TYPE_*, class name and hints) and customize it if needed.
• 3. Add a built-in way to get type names from TYPE_* integers.
• 4. Methods to retrieve methods, properties, signals ecc names from Script Resources (NOT script instances). Expose Script reflection methods to scripting API. godot#31021
• 5. Inspector plugins tutorial in the docs is really bad, should be improved. [3.x] Improve Inspector plugin tutorial with a better example godot-docs#5156
• 6. Add a convenient way to get the current editor theme and use it in tools to get colors, icons, ecc.
• 7. Add a way to precisely listen to files/resources creations and removals in the project filesystem. This would be very useful whether a plugin wants to be aware of all the resources of type TypeA to create custom dropdowns, lists and many other powerful tools.
• 8. Add a convenient way to mark properties (methods, signals...) with custom export hints, so that inspector plugins can take action whenever needed for example. Something like annotations should be great. Allow custom GDScript annotations which can be read at runtime #1316
• 9. Ability to properly export custom Resource types. Add first-class custom resource support #18
• 10. In general, make it very easy and quick to recreate editor-style controls and UIs.

Describe how this feature / enhancement will help you overcome this problem or limitation:

All this additions will bring much more freedom and power to users creating editor plugins.
Some of the benefits are already explained above.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

Describe implementation detail for your proposal (in code), if possible:

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

Not quite, if possible, the workarounds are inefficient, slow or not convenient.

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

It's a set of improvements that would allow better add-ons, not possible to implement with add-ons themselves.

[Xrayez]

2. Expose EditorInspector:instantiate_property_editor, or a method that does the following, users can automatically instantiate the right EditorProperty (based on TYPE_*, class name and hints) and customize it if needed.

I can confirm that it's quite tedious to re-implement those property editors. For instance, I tried to expose some editor settings in a dock. While it works for simple properties, it becomes ever more difficult with all those hint strings on top of that, so I'm very reluctant to do anything with it currently.

6. Add a convenient way to get the current editor theme and use it in tools to get colors, icons, ecc.

That's definitely something which requires quite a lot of steps, you basically need to fetch Godot base control for that.

[nonunknown]

thread godotengine/godot#35743 complements this one! _{bugsquad edit: fix link}

[nicktgn]

1. Expose all editor types, at least those useful to create plugins, like the subclasses of EditorProperty, various dialogs/containers (to select a property from a node or resource, to select a method, to create a Node/Resource, ecc). Also in the Create Dialog, maybe hidden by default and displayed only if explicitly selected in a dropdown menu. (like in the Search Help dialog)

This would be so helpful. With this making custom inspectors for your custom resources / data types would be a breeze. In majority of cases all you want in custom inspector is just to arrange a bunch of built-in EditorProperty controls in a way that is more suitable for editing your data type. But currently you have to re-implement every built-in control you want to use.

Actually, is there anything that currently prevents exposing existing EditorProperty subclasses to GDScript side?
Or should we do this instead godotengine/godot#26946 ?

@akien-mga @reduz
Would like to hear opinion of core devs on this one.

[auralluring]

I've spent the last couple days creating a custom dictionary editor, (because the default one sucks, but that's a different topic) and having the vanilla EditorProperty types available (including the dictionary one, if I had that I would just have to override the update_property function and I would be set) would have made the whole process 100x easier. I didn't even know they existed until I tried to name one with the same name and it wouldn't let me. And since dictionaries can have keys and values of any type, I've had to recreate an editor for every single one.

Also, can we please get/ is there a way to turn off the labels? (selectively of course) I'm trying to make the keys editable by having them be EditorProperties themselves, so therefore I don't need them.

One last thing: there needs to be more resources for this stuff. I've never searched through so much source code.

[AnidemDex]

Can this proposal be updated pointing where already marked points are solved?

[samdze]

Updated.
Also, let me know if any of the above points get addressed.

[AnidemDex]

I think that point 6 can be done with

<EditorInterface>.get_base_control().theme

---

9 may can be related to #18 ?

[YuriSizov]

I think that point 6 can be done with

<EditorInterface>.get_base_control().theme

6. Add a convenient way to get the current editor theme and use it in tools to get colors, icons, ecc.

Due to the nature of how themes work there is no need to expose anything. Any control added to the editor's UI tree can access the editor theme. You can freely use any property defined on the editor theme.

You can use this theme explorer plugin to learn what definitions are there in the editor theme:
https://github.com/YuriSizov/godot-editor-theme-explorer

If for some reason you need to reference the theme itself, Dex is correct with that code snippet (and it's in fact what the aforementioned plugin uses to fetch all the definitions). But again, you don't need to fetch it and assign to your UI. Your controls already have access to the theme due to the way themes in Godot work.

---

9 may can be related to #18 ?

Yes, it's covered by #18.

[Bindernews]

I would really like to see points 1 or 2 implemented. I was trying to make an inspector plugin to allow applying Transform2D matrices to polygons. It would be easy if I could just add the already existing Transform2D editor below the polygon, with a dropdown to hide it. But I'd have to re-create that all from scratch, so for now it's not worth it.

I even tried to instantiate the editor classes using ClassDB but it seems they can't be created from GDscript at all, only C++.

[CardboardCarl]

I'm in favor 1 and 2 and 3 as well, and frankly I'm puzzled as to why it's taken 5 years without being addressed. Are there any limitations in the codebase currently preventing this from happening?

A plugin I was recently working on has basically ceased development because it required access to multiple EditorProperty inspectors that I only now figured out aren't exposed to GDScript. I could try my hand at experimenting with exposing them and open a pull request if that would help.

Edit: inspector-gadget is also available as an alternative, but it feels more like a workaround when the editor already comes prepackaged with the same functionalities

[AnidemDex]

Are there any limitations in the codebase currently preventing this from happening?

Exposing internal functionality means that it can't be changed too often to maintain compatibility between versions, which also means that somebody has to maintain those classes and their functionality; without mentioning that those are just editor classes, so they can't be used in game afaik

[AnidemDex]

3 is already solved with @GlobalScope.type_string() (just type_string)

6 is already solved using the editor theme (either getting it from EditorInterface base control or EditorInterface.get_editor_theme()). Name references can be seen in Theme editor.

8 is already solved using _get_property_list or _validate_property, or is it related to something else?

---

Isn't 7 related to FileSystem? It has some signals related to that.

[CardboardCarl]

Exposing internal functionality means that it can't be changed too often to maintain compatibility between versions, which also means that somebody has to maintain those classes and their functionality

I guess it would really come down to if the Foundation (or whoever else is responsible) decides the EditorProperty system in Godot currently is functionally complete enough to stay basically the same as it is for the time being.

If it's going to function mostly the same even, say, 5 years from now, it probably would be fine to expose the built-in properties, since even if the functionality of a property has to change slightly for some reason, its job is only to modify already existing data types. As long as the most an EditorInspectorPlugin is doing with them is instancing them and linking them to a variable, there's basically a 0% chance a change would break compatibility. Or am I missing something critical?

Error handling would have to be fleshed out further though, if it isn't already, to prevent linking to properties with mismatched types.

without mentioning that those are just editor classes, so they can't be used in game afaik

Yeah, that was already a given. This is mostly to be used by EditorPlugins anyways.

[Caellian]

3. Add a built-in way to get type names from TYPE_* integers

type_string(type: int) produces the name of TYPE_* integers which can be accessed from typeof(value: Variant). So this one is complete.

[AnidemDex]

@CardboardCarl

its job is only to modify already existing data types.

Are you aware that editor properties are a lot of nodes? There even was a long discussion about exposing a single one (EditorResourcePicker) back then.

there's basically a 0% chance a change would break compatibility. Or am I missing something critical?

The point is not about if it'll break something between versions, it is about someone who will have to make sure that it doesn't break between versions for more people than just the engine contributors, probably covering more things to fit user needs and maybe exposing other related classes that makes them work.

[AnidemDex]

@Calinou this may be off topic: can the already solved points be updated in the original issue description?

[Calinou]

@Calinou this may be off topic: can the already solved points be updated in the original issue description?

Which points do you think are currently solved as of 4.3? I can think of 6. right now.

[AnidemDex]

Which points do you think are currently solved as of 4.3? I can think of 6. right now

3 is solved with type_string()
6 is solved either just adding the desired control node to EditorIterface base node or with EditorInterface.get_editor_theme()
7 is solved with EditorFileSystem and related classes, unless OP wanted something more specific.
8 is covered with _validate_property where it can modify the property definition. Some cases can be covered with _get_property_list too, unless OP wanted custom @annotations

Edit: fix md format

[smedelyan]

Regarding p.1, AFAIU the only concern Godot may have about exposing the API is the liability to support all this throughout the time and inability to change API without breaking anyone's work.

If this is the only big problem, can we just copy / move the implementation of inspector displays to a separate (possibly, mirror?) repo that everyone can import as a plugin? I believe, lots of people will be absolutely happy to use this plugin even if it is explicitly stated that its API / behavior may change with no further notices or not work correctly in a newer Godot version.

---

EDIT
I don't think we may need all the functionality inspector has under the hood, but at least replicating most of controls and displays. If that helps speed up things, I think we can even start with a stripped-down version of inspector (e.g. no support for node signals, just displaying and editing props) and build upon that sequentially

[Calinou]

If this is the only big problem, can we just copy / move the implementation of inspector displays to a separate (possibly, mirror?) repo that everyone can import as a plugin?

Inspector functionality is written in C++, so it can't be an editor plugin without being ported to GDScript (which has performance implications). Also, the entire editor must be able to function on its own even if GDScript can't run for some reason (e.g. if it's disabled at compile-time). The same applies to GDExtension.

[docfail]

If I am honest, I feel point 8 in the original proposal here has been marked complete erroneously.
Unless I am missing something in these docs here Godot 4 still does not support custom export information as of the current stable release. There are admittedly a lot of useful miscellaneous types of export annotation built in but they certainly do not cover the ask for "custom export hints, so that inspector plugins can take action whenever needed for example" in that point. I am confident the existing implementation(to my knowledge) isn't in the spirit of the proposal because they specifically mentioned "something like annotations" which to date still have not been implemented. See #1316 which still seems to be getting discussed, even though it looks like the conversation has hit a bit of a dead spot.

[docfail]

Also, it looks like there is a PR out for point 2: PR #87375 if I am understanding it correctly.
Appears to just be waiting on an approval?