Add node dock category system for better node selection (optimization for `class_name`-ed node classes piling in the main node dock that is led to a mess)

Describe the project you are working on

Any project

Describe the problem or limitation you are having in your project

(I think this could be a better solution for #1047 and #4493) Currently, since we have no any idea to handle the messy node dock because of our dependency on class_name, there have been two solution proposals suggested to solve the problem, to which here a great thanks should be given to these two proposals. However, even though these two have one thing in common — to hide the node beginning with class_name from the dock with either an annotation or a keyword, what if we have to instantiate them directly from the dock? Our goal, to be clearer, is not to simply hide the class_name-ed classes, but to move them to other places that can keep the main node dock clean and tidy, isn't it? So this proposal is taken onto the table, providing (maybe) a better solution for this inconvenience.

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

Add an annotation @class_category(category_name: String, show_parent: bool = true, show_children: bool = false) to the engine that will split the node from the main node dock, which should be placed at the same position as @tool, @icon and @static_unload. Note: This is not namespace that will provide codical group separation from the main codical group. This proposal is only for node dock!

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

Basic usage

At the top of a custom class script beginning with class_name, use @class_category() annotation to move the node from the main dock to other one:

@class_category("My Category")
class_name MyPubClass extends Node

At this moment, a new tab will be shown in the main dock When clicking on "My Category", everything will be cleaned and the nodes in this category will be shown

Inheritance

If another class extends MyPubClass without @class_category() assigned, this node will be, by default, classified in the same category as the parent's

class_name MySubClass extends MyPubClass

If, in the child class, assigned with a different category name from the parent's, in the category of the parent class, there will be no direct link to the child; however, in the child(ren)'s, a link will refer to the parent's icon with its name in cyan color.

@class_category("Others..")
class_name MySubClass extends MyPubClass

And double click the parent in this category will navigate to the tab where the parent is displayed.

Customized Displaying of Children or the Parent

If a developer dislike to make the node shown, he/she can set the second parameter of @class_category() to false.

@class_category("Others..", false)
class_name MySubClass extends MyPubClass

Then no parent class will be shown in "Others.." category: In addition, if the developer want to show the child node classes in other categories, he/she can make the third parameter of @class_category() true.

@class_category("Others..", true, true)
class_name MySubClass extends MyPubClass

Thus all the children will be shown in the parent's dock:

Back to main/root

If you want to keep the node shown in the original main/root tab, just assign @class_category(""), or remove the assignment of the annotation if the node directly inherits the built-in node classes.

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

If possible, a plugin could work, but I don't know if the plugin supports editing the node dock... So maybe yes or not.

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

See the previous chapter above.

godotengine / godot-proposals