feat: Add usage statistics for applications to improve search results

[AnyTimeTraveler]

I added a small module, which allows anyrun to keep track of how often an entry has been launched.
Anyrun can then use these statistics to improve the search ranking of these applications.

There the applications plugin has gained the following configuration options:

use_usage_statistics: bool
/// Whether to put more often used applications higher in the search rankings (default: true)

usage_score_multiplier: i64
/// How much score to add for every usage of an application (default: 50)
/// As a reference: Each matching letter is 25 points


max_counted_usages: i64
/// Maximum amount of usages to count (default: 10)
/// This is to limit the added score, so often used apps don't get too big of a boost

An amended configurations file has been provided that mirrors the default config, just like the config.ron does for the main application.

Since I see no downside to this, I have chosen to enable this feature by default.

Please let me know, if you'd like me to make any changes.

[Sntx626]

This is a somewhat opinionated review, however I think we could greatly improve the utility of the usage statistic system if we calculate the weight using logarithms.

The proposed changes have been added as comments to the code.

[Sntx626]

I don't like the max_counted_usages option, since a low number will diminish the function of the history, the longer anyrun is used. If all applications have been launcher at least 10 times, where's the benefit?

[AnyTimeTraveler]

The benefit is just over the applications that haven't been used at all.
Technically, it would be enough to be able to mark an application as favorite, to give it a static boost over other apps.
Since I did not want to add interactivity to the plugin (because it's massively more complicated and would entail editing the base application), I chose to use a simple algorithm that would count up to 10 usages to give an app the full bonus score.

This way, you can accidentally launch an app a few times, without it impacting the score too much.
There are probably more advanced ways to do this, but I only spent an evening on this and it's good enough for my current purpose.

In another comment, you mentioned logarithms. I like the idea of capping the upper limit that way, but there would still have to be an upper limit, as to not overwhelm the actual search matches from the fuzzymatcher.

[Sntx626]

Since using a logarithm would disassociate the value from a specific ranking score, we should probably map this to something like:

0: 0% weighting - No effect
1: 100% weighting - Default
1.5: 150% weighting - Preference for weighted entries

This also makes the use_usage_statistics redundant. Though I like verbosity, so maybe we should keep it.

[AnyTimeTraveler]

I would definitely keep use_usage_statistics to enable users to keep filling the usage-file without doing anything with it.
Knowing developers, I'm sure someone will discover this feature and use it this way.

As mentioned in #176 (comment) I like the idea of logarithms, but the usage_score_multiplier and max_counted_usages still needs to exist to balance the score with the score from the fuzzymatcher from the search-results.
If these values (or a version of them) are not exposed, the recency score could overwhelm the actual matches to the query, thus always showing the most used entries.
In reverse, it could also not have any effect at all, if the multiplier is too low.

[Sntx626]

This PR should also close #14 .

I also want to say that we already have a PR #116 that adresses the same issue.

[AnyTimeTraveler]

Originally, I hadn't intended to publish this code, as I only spent an evening on this, including finding good config defaults and testing.
That's why I hadn't looked at the issues or other PRs of anyrun, before making this.

However, having read #14 and found #116 there seems to be demand for this feature, but also a hesitancy to implement in the main applications-plugin.

Reading further through #87 #158 makes it look like the maintainer has plenty of work ahead of them, so I don't think putting any more work in their lap is a good idea.

That said, I'm still open to improving this, but not expecting this to be merged anytime soon.