Refactor editor API to allow deep editor customizations

trollodel commented 3 years ago

Related to #300, #1761, #2276 See also godotengine/godot#47520

Glossary

(UI) component: a relevant part of the Editor UI (e.g. docks, scene tabs, the bottom panel)
subcomponent: part of a component that is big enough (e.g. toolbars, trees)
main subcomponent: the biggest/dominant subcomponent. Other UI words came from here

Describe the project you are working on

Unrelated to the proposal.

Describe the problem or limitation you are having in your project

Currently, the editor API are quite limited.

You can't access all the components using properly getters. Instead, you have to walk the editor scene tree to get the desired component.
Even if you can access to the desired component with a proper API, often it doesn't expose proper getters to subcomponents.
EditorPlugin is quite monolithic and manages most of the interactions with the editor. While this is a good point in usability as everything is there, it creates a giant class with tons of methods.
Properly plugin interfaces are missing in some components.

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

Provide simplified access for most parts of the UI

The idea is to provide different levels of access to the components:

Access components through getters in EditorPlugin or in a proper singleton.
Access from getters in the component to complex subcomponents or specific (complex) nodes that represents the predominant part of the UI (e.g. trees in the Scene dock and in the FileSystem dock). The granularity of getters should be discussed, but the intention is not to expose every button or worse.
Access though node names. Mostly for containers with homogeneous kind of node (e.g. containers of buttons). See #1018
Access walking the tree. Mostly for labels, buttons, containers or other component that are only used for aesthetics, or they are too dynamic to be accessed directly.

Group editor components in singletons

In a complex UI like the Godot Editor, it is necessary to split and group all the component interfaces. So I propose to have several singletons, obtainable though EditorPlugin.

EditorDocks for docks and to get the builtin ones.
EditorWorkspaces for workspaces and to get the builtin ones.
EditorBottomPanels (or just EditorPanels) for panels and to get the bultin ones.
EditorComponentPluginInterface (! better name required) for managing component-specific editor plugins. This acts mostly as a helper and the same interfaces (mostly adding/removing plugins) must be exposed by each component Note that some panels are showed depending on the context (e.g. Animation) so they may not be available.
... and other ....
EditorInterface (I prefer EditorRoot) for top level plugins and getting the main menu, the playtest or other interfaces that does not belong to other singletons.

Other enhancement

Each component must expose its API and not delegate it to high-level classes (like EditorPlugin).
Add new component-specific plugin types.

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

Most was described above, but an editor plugin entry point should look like this (in GDScript):


@tool
extends EditorPlugin

const import_plugin = preload("res://addon/mybigaddon/import_plugin.gd")
const dock =  preload("res://addon/mybigaddon/dock.gd")
const top_level_control = preload("res://addon/mybigaddon/top_level_control.gd")

func _enter_tree():
    var editor_docks = get_editor_docks()
    editor_docks.add_control(dock.new())

    var editor_comp_plugin_interface = get_editor_component_plugin_interface()
    editor_comp_plugin_interface.add_import_plugin(import_plugin.new())
    # or
    var import_dock = get_editor_docks().get_import_dock()
    import_dock.add_plugin(import_plugin.new())

    var editor_interface = get_editor_interface()
    editor_interface.add_top_level_plugin(top_level_plugin.new())

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

Not always, while it is possible to get every node navigating the scene tree, some nodes have internal objects to manage their status and appearance, and they are not available mostly.

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

Requires changes in the editor.

Unrelated to the proposal

Expose and allow instantiation of internal editor nodes or helpers.

me2beats commented 3 years ago

As for the docks and bottom panels in general, I think that calling the components "docks" or "bottom panels" is kinda short-sighted, since in the future these components might be floating, or be located on a main screen, etc.

Dock, panel, floating window etc are just options for the arrangement of components/plugins/editors imo.

I think it would be more sensible to have a Components and Plugins singletons.

Components singleton - for built-in components/editors/plugins (such as ScriptEditor, FileSystem dock/view, SceneTreeEditor, Inspector, ShaderEditor etc.), This Components singleton could have methods like
```
get_component(component_name - String or enum)`
```

And Plugins singleton could have methods and singnals for working with user plugins such as:

get_plugin(name: String)
set_enabled(plugin_name: String, enable: bool),
get_enabled(name)
get_plugin_list()
#as well as maybe:
add_inspector_plugin()`

and others like that.

trollodel commented 3 years ago

As for the docks and bottom panels in general, I think that calling the components "docks" or "bottom panels" is kinda short-sighted, since in the future these components might be floating, or be located on a main screen, etc. ,Dock, panel, floating window etc are just options for the arrangement of components/plugins/editors imo.

This would be nice when it happens, but unfortunately this is not the case right now. Each place has a different API, and they are not trivial to merge in a unified API, especially the main screen/workspace one.

I think it would be more sensible to have a Components and Plugins singletons.

I had though about having a Plugins singletons (I'm always talking about editor plugins, as other kind of addons should be separated IMO), but it is a bit out of scope of this proposal. However, Plugins should not contain methods like add_component_plugin() as they are mostly a convenient shortcut for get_component_dock().add_plugin().

Instead, a Components singleton would become a giant class with dozens of methods (to give you some numbers, there are 6 docks, 14 bottom panels and 4 workspaces, and I'm missing other components such as the main menu) and it's something that I want to avoid as, in the current state, there is a hard separation between component "types".

get_component(component_name - String or enum)

I prefer having separated getters as each component has a dedicated API for its customization, and for type safety/autocompletion stuff.

trollodel commented 3 years ago

All the linked PRs were rejected, but I'm not going to close this because the listed issues still exist and an alternative solution (but related) was discussed in the Godot contributor chat. Also, this is the only existing proposal where there is a generic solution for the listed issues.

godotengine / godot-proposals