Fix search window sluggishness

[10110111]

The Search dialog is currently implemented in a very suboptimal way, especially since #4635, when it started triggering searches by name in its CompletionListModel::data method. The search is supposed to get object type for each item found, which is only a name of the object.

What the dialog would really want is to have object pointers in the search results, not simply names. This requires a huge refactoring of the search API in StelObjectModule, so that the list-object methods return the object pointer. This is exactly what this change does. In addition to the pointers the API still returns the names, because it looks like the right names for search results are not always trivial to find out.

Now, I needed to split the finding of the double and variable stars to initialization stage, because otherwise it'd have to be done synchronously during a search, which is not nice. It appears that R And doesn't get found easily and somehow requires a search for a Gaia object, which then stumbles upon the fact that StarMgr is initialized before StelSkyDrawer, while such a deeper search requires StelSkyDrawer. I've replaced the R And designation with HIP 1901 (in b166597), but I'd like to know if any of the other stars could face a similar problem in some circumstances. Maybe we should simply change all the designations in the list to catalog numbers for ease of search.

I'm leaving the searchByName and searchByNameI18n calls in SearchDialog.cpp for now, but hopefully it won't be required anymore.

I'm marking this PR as a draft because it's the first appearance of this huge change, but I think it's fairly complete and ready for reviewing.

Fixes #4655

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

This is an automatically generated QA checklist based on modified files.

[10110111]

So the comments about R And have been addressed now. But how can I reach StarMgr::listAllObjectsByType as a user, so as to check that it behaves as expected?

[10110111]

BTW, there's also another change that I introduced in some modules: the use of a QMap to avoid the need to implement sort+removeDuplicates that was available out of the box in QStringList. This affects constellations, nebulas, nomenclature, Solar system, and stars (easily findable by looking for map; in the diff). It seems the automatic sorting by key doesn't hurt there, but I should note this here anyway.

[10110111]

But how can I reach StarMgr::listAllObjectsByType as a user, so as to check that it behaves as expected?

This method gets called by the Search dialog from its fourth tab, Lists.

[alex-w]

I didn’t checked the code yet, but what about changes for list of latest founded objects in search tool?

[10110111]

what about changes for list of latest founded objects in search tool?

What changes? The type is saved to the config file and loaded from there.

[10110111]

Hmm, Peacock is broken...

[10110111]

Actually, the whole search mechanism is broken: even in master there's no way to find both types for homonymous objects, because the names are keys in a name-type map. And the storage of the recent searches also uses this map, so there's no way to store such results.

[alex-w]

Actually, the whole search mechanism is broken: even in master there's no way to find both types for homonymous objects, because the names are keys in a name-type map. And the storage of the recent searches also uses this map, so there's no way to store such results.

But maybe you're expanded the feature? ;)

P.S. I checked the branch yesterday as an user and it works better than master

[10110111]

But maybe you're expanded the feature?

No, I haven't expanded it. The issue with Peacock appeared now because of the order of results that doesn't play well with the last stored names in the Search Dialog's name-type map. Previously this wasn't a problem because whatever was found by name was both the item that was selected on goToObject, and the one whose type was displayed. Now these data are separate.

The proper solution is to completely redo this module-type feature, saving a list of name-type pairs instead of a map into the JSON, and storing it likewise in the C++ code.

[10110111]

There appear to be two different object "types": one returned by StelObject::getType(), anther from StelObject::getObjectTypeI18n() (or StelObject::getObjectType()). Very confusing. Only the former can be used for searching (and it was done in gotoObjectWithType, which was connected to a completely different list of objects, again utterly confusing), while the latter has to be shown to the user.

I've rewritten the logic of the search, so that there's only one method that actually searches for an object and selects it, and both kinds of type are now stored, including in the recent object history.

[10110111]

One small issue now is that, when we go from the list of objects, user-visible type is not registered in the Recents. I'll fix that later.

[10110111]

So far all the issues I had identified are fixed. The legacy Recents list is now ignored, only the new-format entries will be loaded. I think it's not too much of an issue.

[alex-w]

Thanks for refactoring the feature