| Summary: | Refine the order of krunner results regarding launch count boost | ||
|---|---|---|---|
| Product: | [Plasma] krunner | Reporter: | stephan.leineweber |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | alexander.lohnau, natalie_clarius, nate |
| Priority: | NOR | ||
| Version First Reported In: | 5.26.4 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
stephan.leineweber
2022-12-16 10:27:19 UTC
>maybe make the launch count boost weighting a bit stronger inside of a category so it can outweigh the "better match" of the entry that is almost never used.
That is architectually difficult, because we have both the match type and the relevance. The latter gets increased for often launched apps. Though if the match type of one result is higher, we always show it first.
I will give it some thought when I find the time. Quite busy with my bachelor thesis ATM.
(In reply to Alexander Lohnau from comment #1) > >maybe make the launch count boost weighting a bit stronger inside of a category so it can outweigh the "better match" of the entry that is almost never used. > > That is architectually difficult, because we have both the match type and > the relevance. The latter gets increased for often launched apps. Though if > the match type of one result is higher, we always show it first. > > > I will give it some thought when I find the time. Quite busy with my > bachelor thesis ATM. If we move the launch count boost logic into Milou, I suppose that we could multiply the launch count boost with both the match type and the relevance check in the lessThan function? I do not think moving logic to milou is the way to go. Especially because we need to keep compat in KF5 and in KF6 we want to move the model to KRunner. If we decide to make the relevance increases more aggressive, we can do that in KRunner too. Otherwise, we would end up with very different sorting when one has a different/custom model which uses the sorting values provided by KRunner. Also, we need to keep track of what matches have been run by the user. This is done in KRunner too, because that is the most central place where we have all the info. This allows us to keep the storing of the launch counts internal, and thus we are more flexible if we decide that we need to adjust the data we are saving This thing seems to be improved, at least for me the strange ordering of the mail clients is no longer existent, every suggestion of krunner seems to make sense now for me. Thanks for refining the order - I'll mark it as fixed now! |