First of all what we currently do:

• For each match that gets executed we store the match id and increment the number how often it was run in total
• When the runners add the matches we *magically* change the relevance m.setRelevance(m.relevance() + 0.05 * count);

This has some issues:

• We modify the relevance, even if the runner has its on relevance system. Lets say when the results are sorted by recently used or more complex sorting as in https://invent.kde.org/plasma/plasma-browser-integration/-/merge_requests/20/diffs#872f696c8492264ae0711909d657ace8c320d77a_0_249 proposed.
• We store this data, even if the runner does not need it. For example the web shortcuts runner produces at most one result.
• Storing the ID can be a privacy risk. In the vast majority of cases the ID gets set automatically from the data of the match. Lets say the user opens a bunch of URLs using the locations runner and then clears the history the data is still on disk.
• Storing how often a match gets executed does not make much sense, if we do not have the context for it, this can lead to confusing scenarios, like:

What we actually want to to:

• We want to adjust the relevance based on the launch counts and take the context into account. I am not sure how we can best do this without having privacy issues. Because we need the information: What has the user typed, and which match was executed. (maybe which runner the match belongs to?)
• We again have the struggle that the relevance is not the single-source-of-truth when it comes to the sorting, the MatchType is more weighed. This makes it kindof useless, see https://bugs.kde.org/show_bug.cgi?id=424505
  • Could it make sense check how often matches from the runner got executed?
• Make it optional to store the LaunchCounts for the runners, in case they have their own sorting mechanism we do not want to mess that up. This is actually the easiest part ;-)