Currently KRunner uses mental multi-threading for everything. QIcon::fromTheme isn't thread-safe, for instance. It also doesn't have a concept of what a result is, so you can end up with duplicate results from different runners, like Baloo, Recent Documents, etc. Furthermore, writing (and distributing on the store!) 3rd party runners could be a lot easier by not requiring one to write a binary C++/Qt plugin.
The idea is to:
- Reduce the thread usage overall. It is still needed for some runners but certainly not having every single runner in its own thread all the time
- Add a concept for entity type, e.g. "file at ~/foo.txt with mime type text/plain", "application org.kde.foo", also check out Core Spotlight CSSearchableItemAttributeSet for inspiration. This way it could also provide richer results and additional actions automatically for certain results, e.g. "open containing folder", preview, file attributes/metadata for "files", etc
- Come up with better scoring for results. Currently each runner has to set a global number from 0 to 1 which just doesn't scale
- Make dbus runner a first-class citizen, so people can easily write custom runners just by slapping together a python script.
- Out of process stuff. krunnerd external process queried by Kickoff, Krunner, whoever? Being able to query multiple krunner dbus services could also be used for compat, i.e. have one "krunnerd5" which is just the old KRunner with all its plugins and then gradually migrate over to the new thing without breaking the whole runner ecosystem again?
That entity type could also be useful for Kicker which currently uses a heuristic to guess the entity type from a kactivitymanagerd UUID. Maybe schema.org / kitinerary stuff could make sense in this context overall? I surely don't want to go down that whole nepomuk ontology rabbit hole, though :)