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) #8675
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:
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.
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.
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?
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 withclass_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 theclass_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 notnamespace
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: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
![2.png](https://i.postimg.cc/QtVGvjdW/2.png)
Inheritance
If another class extends MyPubClass without
@class_category()
assigned, this node will be, by default, classified in the same category as the parent'sCustomized 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()
tofalse
.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
.Thus all the children will be shown in the parent's dock:![6.png](https://i.postimg.cc/nrWH30bB/6.png)
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.