Any minimal project to make testing this easier?

Any minimal project to make testing this easier?

https://github.com/beicause/godot-cpp-template/tree/test-class-icon

I am not sure it supersedes my implementation, it seems more like a parallel functionality. From what I take from the code, is that you take the parent class, and use that icon, right? I didn't go this route because I was told it wasn't possible back when I implemented this, but that would've been a previous default. Correct me if I'm wrong, reading Godot code feels like a puzzle most times, but I don't think your pr gives the user the ability to use the icon "Sprite3D" on a subclass of "CharacterBody2D", and that was indeed my intention. I find most times I don't want to just use the superclass icon, but an icon that best represents the new class I'm making, and I always find myself having to go through godot/editor/icons, choose an icon, copy and paste. I believe the algorithm should work like this:

• If path to icon provided
  • If icon exists, use icon
  • If icon doesn't exist, but has the same name as an editor icon, use that
  • If none of that works, treat the path as nonexistent
• In case it doesn't exist, or if the previous step failed
  • Use superclass if found
  • Use default fallback otherwise

I suggest we work together to implement this algorithm to cover all of it in one go, if you'd want, otherwise you can do it or I can do it

Yes, I believe this PR is compatible with yours.

In my opinion automatically using the parent class icon is sufficient. Exposing the editor icons means additional compatibility burden. I'm not sure if it's actually useful.

If you want to implement that, I think you can make the changes in extension_class_get_icon.

I did implement it in my PR, so it's just matching both codes.

In any case, yes, it is really useful. If I make a Node that represents a Ball, I'm going to be using Sphere3D instead of probably anything I've inherited, it gives better visual information.

Plus, I believe it's needed for feature parity with GDScript, since GDExtension should be a first class citizen of Godot.

You can continue implementing it in #100298 based on this PR and resolve the conflicts - just make sure to return the icon before falling back to parent class icon.

In any case, yes, it is really useful. If I make a Node that represents a Ball, I'm going to be using Sphere3D instead of probably anything I've inherited, it gives better visual information.

In this case, I think it's better to copy&paste it or make one.

You can continue implementing it in #100298 based on this PR and resolve the conflicts - just make sure to return the icon before falling back to parent class icon.

Sure, when I have the time, then.

In this case, I think it's better to copy&paste it or make one.

But that's the whole problem all the time, we'd like to access the already made icons instead of having to source a new icon for every new node we make. Sure, using the parent icon is better, than a blank node, but it still can be used to pack more information. Right now I have to update a line of code and search through godot/editor/icons for it, copy, and paste it. It would be much easier to just have to update the code, since it's easily accessible data for Godot, and clutters less the project with things that are already there.

Great! I'd suggest a rebase before merging as the last update was 3 months ago (and a quick check that no new code needs similar changes).

Thanks!