Reorganize a subset of Editor features into a module of reusable nodes and resources to complement /scene

[willnationsdev]

Describe the project you are working on

Literally any plugin that adds GUI elements to the Godot Editor, e.g. a potential plugin for satisfying #13 (which I started thinking about now that godotengine/godot#44879 is in a good place).

Describe the problem or limitation you are having in your project

The Godot Editor has many tools built into it that are valuable for editing data related to Godot projects.

• Custom editors for various types of resources (like curves, shapes, scene trees, etc.).
• Utilities for searching the class architecture and building instances (like CreateDialog).
• The Inspector which can generate a competent GUI for editing data purely from a selected Object and its list of property metadata.
• All EditorPlugins that add special interfaces or overlays to the Viewport.
• The Godot Asset Library and its ability to list, select, search, and fetch data related to remote web endpoints.
• Many more custom tools that are exclusive to the Godot Editor.

All of these are, generally speaking, "basic" reusable classes and features that are useful for building all sorts of GUIs associated with Godot projects.

• Creating options menus for games.
• Creating applications designed to work with a viewport and live-edited data (Pixelorama, Material Maker, BlastFX, Wonderdraft, etc.). Many EditorPlugins in the editor code could easily be used in such projects.
• Creating level editors within a game.
• Creating separate modding tools for one's own game.
• Creating plugins for the Godot Editor in script code, without access to the Editor's internal C++ types.

This is a vast, ready-made collection of community-maintained and battle-tested tools that no one can use for their plugins or projects simply because they aren't exposed to the scripting API, so everyone has to needlessly reinvent the wheel with custom assets.

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

I propose that much of the Godot Editor is refactored into a larger collection of more generically written tool nodes and resources which the current /editor codebase then builds upon by extending those classes and customizing them for the Godot Editor we know and love today. BUT, these generically written tool nodes are, like /scene directory, exposed to the scripting API, so everything outside of the Editor can also use them.

This would expand the out-of-the-box features available to those who use the engine without significantly bloating it since all you're really doing is moving around and re-contextualizing what is already there.

In addition, it stands to greatly improve the future of the Editor itself by refactoring it to be more flexible. For example, the entire Godot Editor assumes only one instance of the Inspector exists. Or that there is only one Viewport into the game world. Or that you only have a single edited scene, etc. These kinds of assumptions limit the Editor from supporting more use cases than it should be able to. If you refactor most features to work with a generic collection of nodes, then it forces the removal of all of those assumptions.

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

I don't know the exact form this would take in the codebase build-system. Perhaps a separate top-level subfolder that builds on /scene, is used by /editor and /modules, and can also be toggled off like any other module, except that it's on by default and is forced on if you compile with tools=yes? Or maybe it's just a regular module that's a special case in the build system. Idk.

So, unlike /modules, the Godot Editor would be able to directly depend on classes defined there, just like /scene. And unlike /scene, users would be able to optionally remove the entire collection of types from their engine build just like they can any other module.

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

The point is that the Godot Editor itself is a massive suite of tools, and anyone wanting to build anything remotely similar to the Godot Editor has to write it all themselves with a huge amount of script code. So no, it's the antithesis of a few lines of code. And it would be used by a massive number of Godot projects.

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

Again, these are things already in core. They simply need to be exposed.

[Calinou]

• Creating options menus for games.

The project settings/editor settings dialogs would be a poor fit for options menus. Options menus in games have very different needs. This is because the project settings/editor settings is really intended to be an advanced settings dialog for the tech-savvy, whereas a game options menu needs to be easy to use on any input device, including controllers and touch input.

[willnationsdev]

@Calinou I was actually more thinking of an Inspector-like node when it comes to in-game options menus. If you just want to have something that knows how to quickly generate a column of labels and editors related to modifying an object's data, it would make building those kinds of things a lot easier, without you having to write custom code for the editors. But all the same, yeah, it would need to be designed to support different kinds of user input.

[me2beats]

It would be great especially for creating apps and different in-game editors

Although the problem is that many of the Godot editor's nodes are not yet ready for use outside the editor (in plugins / games), at least because they have a tangle of dependencies that are not needed when used outside the editor.
It will also be important to create a logical node infrastructure (built-in node configuration warnings, etc.)

I think we need to carefully consider API and infrastructure of each such node, and most likely it is worth a separate proposal for each one.

For example, in my plugins I miss some nodes from InputMapEditor dialog, such as "Press Any Key" popup, where the user enters the shortcut in a convenient way.
I think it would also be useful to have it in games/apps that allow you to customize the input.
Also, for example, when creating apps/games which use 3D editing, it would be useful to have a gizmo node, when creating a text editor - scrollable text minimap (which the Godot code editor has), in apps working with files it would be convenient to have a simplified version of the FileSystem dock etc.
However, again, I believe each node should be detailed and discussed in a separate proposal.

[Calinou]

scrollable text minimap (which the Godot code editor has)

You can already enable the minimap in the TextEdit node properties.

[neikeq]

I also want this to be proposal to be realized. A very missed feature from Unity is how the editor (inspector, viewport, gizmos, selection, etc) can be used on a running game. Since it seems this won't be happening in Godot, making the editor components usable in games would be a great solution.

Although the problem is that many of the Godot editor's nodes are not yet ready for use outside the editor (in plugins / games), at least because they have a tangle of dependencies that are not needed when used outside the editor.

Not only that, but a lot of it is hard-coded to interact with other parts of the editor. So making them usable in games would require changing that and writing the code with re-usability in mind.

[Xrayez]

Yeah, I think this proposal makes perfect sense. It's a matter of organizational and refactoring changes, and adding a SCons option to compile those in non-editor builds (similar to existing disable_advanced_gui=yes, yet the "opposite" of that).

I'm a creator and maintainer of Goost project, and I'd certainly use this option for compiling custom Godot builds with those editor features to be available in non-editor builds (the idea is similar to other proposal of mine: #1632), even if official Godot builds won't use it, since Godot aims to be small, if engine binary bloat is the major concern (apart from maintenance part, like writing documentation, drawing new editor icons for exposed classes etc.)

See also goostengine/goost#81 which is a specific request, and it could be covered by this proposal instead. So, I do think that this is something Godot could allow.

[speeder]

Oh this proposal existed.

Yep this would be EXTREMELY useful, I am making an editor for OpenTTD, like Godot itself but instead of making a whole game, it is to make stuff only for OpenTTD, and I am quite disappointed I can't use Godot existing Inspector and would have to make my own from scratch.

[willnationsdev]

Feel like I should mention @chottokite's comment on a different thread here since they are the first person I've seen to actually say this shouldn't be done. Based on the comment, there appear to be two options...

• a core "editordeps" codebase:
  • share maintenance work that is "updated" automatically
  • shackle the Godot Editor to need to maintain specific tool nodes since they are in use.
• a third-party tool nodes codebase:
  • duplicate maintenance work that is "updated" manually.
  • keep the Godot Editor free to adopt whatever nodes are necessary for it without regard to tools' use in projects.

However, many of those who've commented, including myself, feel like they need these tools and specifically don't want to have to separately maintain such tool nodes. That is, this proposal is a desire to go with option 1, not option 2, and it has a sizable number of upvotes thus far. Would love to hear others' direct thoughts though.

Personally, I think there isn't a reason we can't do both, so-to-speak. Go ahead and have a core codebase that is immediately available to all, and then if the Godot Editor needs to change such that a given node becomes unnecessary to the Editor, it can be moved to a third-party addon for preservation purposes and discarded from the core codebase.

---

I also know that web and mobile release templates are very picky about size, so we might need to amend the proposal to have editor dependencies included by default on tool builds and removed by default in release builds while still being able to easily compile them back in if we need them. What are people's thoughts on that?

[don-tnowe]

I make editor plugins. I could REALLY use some classes that replicate the functionality of Editor's Inspector properties. Numbers have this thing when you drag on the control OR edit via keyboard. Resources have a dropdown with a bunch of options plus file drag-and-drop.

And it's different from using these in games - in editors plugins, it is more desirable to make the controls look like the default and replicate the editor's functionality and looks precisely.

In games though, I think most features in these aren't needed.

[YuriSizov]

Numbers have this thing when you drag on the control OR edit via keyboard.

That's https://docs.godotengine.org/en/stable/classes/class_editorspinslider.html

Resources have a dropdown with a bunch of options plus file drag-and-drop.

That's https://docs.godotengine.org/en/stable/classes/class_editorresourcepicker.html

[don-tnowe]

Numbers have this thing when you drag on the control OR edit via keyboard.

That's https://docs.godotengine.org/en/stable/classes/class_editorspinslider.html

Resources have a dropdown with a bunch of options plus file drag-and-drop.

That's https://docs.godotengine.org/en/stable/classes/class_editorresourcepicker.html

🤨

Alright, guess I just didn't search the right words in the docs then. Thanks!

[YuriSizov]

To be fair, you did pick two of the few actually exposed widgets, but we also have plenty we don't currently expose 🙃

[willnationsdev]

@don-tnowe @YuriSizov Not to mention, even those "exposed" widgets are not things that one can use in non-Editor builds of Godot Engine, so you can't reuse them in custom tools or applications w/o rebuilding them yourself manually or including the entirety of the Godot Editor in your binary.

[3da]

This is really good idea for creating custom game map editors. Would be nice to see it implemented some time.