Add names to editor's controls

[menip]

Godot version:
3.1.1

Issue description:
Ran into this issue while working on a plugin. Editor controls are for the most part unnamed, making it difficult to find what you want. Here is sample output from get_editor_interface().get_base_control().print_tree():

.
@@14
@@14/@@15
@@14/@@15/@@54
@@14/@@15/@@54/@@57
@@14/@@15/@@54/@@57/@@56
@@14/@@15/@@54/@@57/@@56/@@55
@@14/@@15/@@54/@@57/@@56/Export
@@14/@@15/@@54/@@57/@@56/Export/@@1711
@@14/@@15/@@54/@@57/@@56/RecentScenes

This goes on for many many lines, with only the occasional control having a relevant name. Note that Zylann's plugin helps somewhat when exploring editor, but does not solve the issue. With this setup, I ended up grabbing the Play the Project button via get_editor_interface().get_base_control().get_child(1).get_child(0).get_child(4).get_child(0).
It would of been much cleaner to be able to for example:
get_editor_interface().get_base_control().get_node("VBox/TopBar/PlayButtons/PlayProjectButton").

In short: adding names to editor's controls will make at the least some aspects of plugin dev more straightforward.

Steps to reproduce:
Open reproduction project and look at output.

Minimal reproduction project:
New Game Project.zip

[Zylann]

I think nodes of the editor were not meant to be accessed by name from a plugin script. The whole editor was developped with this assumption, so doing what you did will most of the time be a hack that can potentially break things. Although, naming would still help debugging.

[TheDuriel]

The whole editor was developped with this assumption

The problem with that, is that the current Plugin APIs are very lackluster when it comes to being able to actually expand the editors functionality. Want a new dock? Sure no problem. Want to remove the asset library button?

First add a control to the tool bar add_control_to_container(EditorPlugin.CONTAINER_TOOLBAR, freeze_button)

Then path from there: freeze_button.get_parent().get_child(2).get_child(3).visible = false

Want to force all docks to have a specific minimum size, to avoid the stupid inspector resizing thing?

	for i in 8:
		add_control_to_dock(i, nuke)
		nuke.get_parent().rect_min_size = Vector2(256, 256)
		yield(get_tree(), "idle_frame")
		remove_control_from_docks(nuke)
	nuke.queue_free()

Oh my god.

[Zylann]

They could be given names where it makes sense, which means they would be part of the API: they need to be considered, maintained that way, and documented so that we know where they are and how they behave.

It's kind of a dillemma though, because imagine you are developping a tool using GUI nodes (editor or plugin, whatever). Your tool works etc. Then someone wants to extend it, but instead of waiting for a stable API, hacks around its way using node names. So your plugin will be modified "without being aware of it", and if you want to change how nodes are placed, it's a lot easier to break what the extension was relying on, or having the extension break your plugin due to what it does.

One of the goals of EditorPlugin was to hide the mess that EditorNode was, and remain stable longer than the changes that could happen behind the scenes, so you would not need those horrible paths. In a nutshell, it's very fast to develop an extension that way, but API breakage is very likely and sometimes unavoidable (but not always, hence "dilemma" :p).

[TheDuriel]

A good start may be to collect every "container" for all the editors, expanding the EditorPlugin.CONTAINER_XXX list.

[menip]

Adding to container list would be nice. Relative paths more likely to stay same, and as long as "important" nodes are named, their type and hierarchy can be changed in minor version without too much hassle from plugin devs.

[Calinou]

I think the main point of doing this would be to improve editor debuggability, which is especially useful for engine contributors. It'd make the Editor Debugger plugin an even better tool for this.

I'm willing to take a look at naming essential editor controls, but I'm waiting for approval first 🙂

[Calinou]

Closing in favor of godotengine/godot-proposals#1018, as feature proposals are now tracked on the Godot proposals repository.