Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set human-readable names for the editor's nodes #1018

Open
Calinou opened this issue Jun 6, 2020 · 5 comments
Open

Set human-readable names for the editor's nodes #1018

Calinou opened this issue Jun 6, 2020 · 5 comments

Comments

@Calinou
Copy link
Member

Calinou commented Jun 6, 2020

Describe the project you are working on:

The Godot editor 🙂

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

When implementing new features in the editor, it's often useful to refer to the scene tree to see how things are organized. This can be done using print_tree_pretty() or with Zylann's excellent EditorDebugger add-on.

Unfortunately, most nodes in the editor don't have manually-assigned names, which makes this tree much less human-readable than it could be.

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

Assigning names to nodes will make it easier for contributors to work on the editor. This will let them fix bugs and add new features more efficiently.

This can also be useful for add-on developers. That said, we don't make any guarantees as to node names not changing over time, so this should not be regarded as a reliable solution for get_node() in add-ons.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

This is already being done in some places, such as here:

https://github.com/godotengine/godot/blob/f54eda121d975127f68db624265271d39d8dabf3/editor/node_3d_editor_gizmos.cpp#L4257

This proposal is just a matter of doing the same for all nodes used in the editor. Names should use the PascalCase convention for consistency, unless the node name is being displayed in the UI somehow (e.g. for use in TabContainer).

This task should be relatively easy, but it'll take a while to name all nodes in the editor.

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

No, as this is core editor functionality.

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

This is core editor functionality.

@YuriSizov
Copy link
Contributor

YuriSizov commented Jun 6, 2020

Do you propose to name every node of the editor UI or are we going to determine some that are more valuable? I'm not sure that there is any practical benefit from the former.

Also agreeing on naming scheme will be a nightmare, if we are going after each node there is in the UI. 😨


unless the node name is being displayed in the UI somehow (e.g. for use in TabContainer).

There is a way to name tabs directly, instead of relying on node names. Maybe we should do that everywhere too, so that names are less "automated" and tied to the internal names.

@Calinou
Copy link
Member Author

Calinou commented Jun 6, 2020

Do you propose to name every node of the editor UI or are we going to determine some that are more valuable? I'm not sure that there is any practical benefit from the former.

I think the long term goal would be to name every node in the editor. Of course, we'll have to set priorities and start with top-level nodes first (docks, menus, …).

@Zylann
Copy link

Zylann commented Jun 6, 2020

There are many nodes that are only there for layout purposes (containers), naming them might not be worth it.

@me2beats
Copy link

This would also make it much easier to write plugins that find nodes in the editor tree.
It would definitely be much more reliable than get_child(0).get_child(1).. or even get_child_by_types(["VBoxContainer", "HBoxContainer"]).

Sometimes finding a node in a tree is the only way to get a node.

@Calinou
Copy link
Member Author

Calinou commented Feb 18, 2021

This would also make it much easier to write plugins that find nodes in the editor tree.

As I said in the proposal OP, names would not be guaranteed to remain consistent across versions since these are just intended to be debugging helpers. In practice, using names will likely break just as often as using get_child() 🙂

Otherwise, we'd only be able to rename internal nodes in major versions, which puts a lot of burden on contributors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants