Automatically set icons for GDExtension nodes (or classes)

[Zacrain]

Currently I am experimenting with GDExtension for C++ a bit, using Godot 4.1.
When adding a node, which was defined as a C++ class, it will have the grey node icon as default icon. According to the docs ( https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/gdextension_cpp_example.html ) custom icons can be set for nodes via the gdextension file.

Given that the number of nodes can become quite numerous and if most or even everything of the game code is implemented via GDExtension, it is quite tedious to find an appropriate icon, even when using Godots own icons, and add it to the gdextension file.
It's also less intuitive to just leave the default grey node icon for everything.

Therefore I think it would be advantageous to let Godot automatically detect the standard Godot class, which is at the lowest level of the inheritance hierarchy.

For example, consider a simple inheritance hierarchy, e.g., just a new class named FancyButton inheriting from Godot's Button class. When added to a scene in the editor, Godot could detect that Button is the lowest class in the inheritance hierarchy which belongs to Godo't default classes. Then it would automatically assign the appropriate icon to that node.

To be able to override that behaviour one could still provide icons via the gdextension file.

Regarding implementation, I can imagine several approaches - without good knowledge of Godot's source code:

• Using std::is_base_of https://en.cppreference.com/w/cpp/types/is_base_of .
• Alternatively, if using C++ 20 is an option, there is std::derived_from https://en.cppreference.com/w/cpp/concepts/derived_from .
• Using another virtual method which gets called to report the type and set the icon (but that would add code irrelevant to the final exported game).
• Adding another (optional) Parameter when registering the class via ClassDB::register_class<T,B>(), where B would be the base class to use for determining the icon in this example.

In case of multiple inheritance this becomes ambiguous of course. For these cases another virtual method or optional parameter, as stated above, could be useful. By default Godot could choose in alphabetical order.

Since I don't really know Godot's source code, I don't know whether there are even more elegant ways possible.

[Priton-CE]

I am a bit late to this but maybe someone stumbles across this issue at a later point like me and wonders why has this not been done?

I can only speculate but I have gone through the sourcecode and here is my hypothesis:

The logic that determines a nodes icon is defined in EditorNode::_get_class_or_script_icon (found in godot/editor/editor_node.cpp)
Here you can see that unlike CustomTypes which hold their own icon directly in the datastructure the GDExtension node is handled much more closely to the engine nodes, only doing one check with the GDExtensionManager to see if a custom icon was defined in a .gdextension file, as ofc these nodes would not be defined in the theme somewhere, so you gotta check in your "custom theme addon" so to speak.

I assume since GDExtension classes are treated very much like engine classes adding additional logic to get a slightly better default icon is not worth it. Engine developers, when adding a new node, will always define an icon for their node so that bit of extra code would only add overhead when retrieving an icon for a node.
The alternative would be having GDExtension classes be treated like CustomTypes, being their own datastructure and so on. But then that would just make the GDExtension interface "weaker".

Of course you could have the GDExtensionManager just choose the icon of the parent class as well if no custom icon was defined via the means detailed by OP. But then again this is not the same behavior engine classes have and also it adds a decent bit of overhead to the GDExtensionManager needing to be made aware of the engine theme and so on.

So in the end I guess the explanation comes down to: Go down to engine level, live like on the engine level.

[sylbeth]

I took a look at the code and after thinking for a while, even if I don't know of a good way to learn of the parent class and I thought this could work, at least, to ease the work of downloading the icons #11336.