Godot: More generic approach for node smart searching

[groud]

Following #11706, I think this might deserve a more generic approach.

Like instead of testing if it is either 2d or 3d, we could use a "genealogic" distance function.
Something like: the number of parent to reach the closest common ancestor of both the root node type and another one.

This distance would be then used to sort the nodes results

[groud]

ping @toger5 :)

[djrm]

also it would be really cool if the search could contain elements from the brief description, for example searching for GIProbe is kinda misleading, would be cool to get GIProbe as a result of searching Global or illumination (well if thats included in the brief)

[toger5]

I also was thinking about making some actually "smart" searching... But since most names are different and descriptive. I found that the only real issue is for somename somename2D
And that is the easiest fix.
I think the search still could get some improvement in general. For example it does not take into account if the searched letters are next to each other or not. Example: rig should give rigid body more priority than conformation dialog which also gets found.

Search rules that would be cool.

• if the searched characters are right next to each other the found name gets higher priority.
• if the characters (from the search string) are in Uppercase in the found node name -> higher priority
• if the searched characters are Uppercase than the search priorotizes the reaults where the characters are also uppercase. This would allow for shortcut searching N2D would only find Node2D (i think) FD would only find FileDialog. DL only directional light RTL only richtextlabel...
  (of course this would need to be documented somewhere)
• Also the anchestor distance of the parent could be used although i dont really see where this would make a big difference. Except 2d and spatial nodes.
  For examole there is no higher probability the user wants to add a toolButton to a button...
  Or PopupDialog to a popup.
  But i think i see your point. It would just be a more generic less "hardcoaded" approach than the current implementation in #11706.
  Although it might even lead to worse resulta in some situations since there is no real correlation between the child ppl add to a node and their parent type (except the general type. Control node2d spatial...)

So i think the better string paddern matching is more impirtant than the anchestor distance. So if we order the search results by a calculated value, we should prioritize how well the string matches other than the distance to the next common ancestor.

[groud]

No but like when having a GUI node, it's better having first GUI related stuff, then node 2D related stuff.
It's also not to have hardcoded stuff into the engine.
I have no problem with the remaining, obviously plenty of stuff can be used for sorting with more or less high priority.

[toger5]

@groud but don't you think, if we make it too generic that this might lead to unwanted results.
I'm really in favour of categorising search based on 2d 3d AND Control (which is not part of the pr).

Also for ui there needs to be a lot of ugly non generic hardcoded stuff anyways. I hate that... but that is just the nature of user interface things.
But it hink you brought up a really good other point.
Using the typo of the parent where I add the node instead of the scene root.
I took the scene root since I was making this pr based on the idea of differentiating the search based on a 3d or 2d scene. ususally you have one of the two and the most upper parent is one of the two types than. So that this would work well.

But if you root is a Node that does not work.

[groud]

Yeah, sure, maybe you could use the first parent as a reference instead of the root node, that makes sense too :)

[toger5]

But in general I'm really pro: putting more time into search optimisation.
I think the ctrl/cmd + a ->type in really short but precise name -> press enter approach
for building up the node tree is really nice! So if it gets better it's great!

[toger5]

@groud true. maybe both. First the first parent, if it is not of one of those categories Node2d Control Spatial than check the root...

[toger5]

Is there a way to ask class db to get the name of a class without using a string.
like so
Classdb::get_type_name_as_string(Node2d)

[groud]

Still I don't like hardcoded stuff, I think we can find a smart enough distance function. ^^
But that's ok for now. :)

Mybe one day that could be good to have node tagging ?

[groud]

Is there a way to ask class db to get the name of a class without using a string.
like so
Classdb::get_type_name_as_string(Node2d)

Why no Object->get_class() ?

[toger5]

@groud therefore I need to initiate it ? Node2d()->get_class() ?
can I also do it with just the namespace? or a function in class DB which takes the type.
probably it does not hurt to initiate...

[groud]

No I don't this you have to initilize it. More like Node2D.get_class() in fact.
Have a look to the core/object.h file. :)

[toger5]

@groud Thank you! will check that now.

[toger5]

okay there is get_class_static() which is a static method.

so Node2D::get_class_static() I think. (just posting that here as a reminder)

[Calinou]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!