Bug 463109 - Refine the order of krunner results regarding launch count boost
Summary: Refine the order of krunner results regarding launch count boost
Status: RESOLVED FIXED
Alias: None
Product: krunner
Classification: Plasma
Component: general (show other bugs)
Version: 5.26.4
Platform: Other Linux
: NOR minor
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-16 10:27 UTC by stephan.leineweber
Modified: 2023-04-18 19:49 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description stephan.leineweber 2022-12-16 10:27:19 UTC
Hi there,

sometimes I don't know if the launch count boost thing works as expected. Example:
I use geary as mail client, I installed KMail to test it and ran it once (!). From that moment on, when typing "mail" KMail always shows on top and then geary second, even though I choose geary every time for two months now. So it feels a bit frustrating that krunner won't learn that I'd like geary to be first.

Maybe this is a bit unlucky because "mail" is in the word "KMail" but not in the word "Geary", and so despite the fact I use Geary in 99.8% of cases krunner thinks KMail is a better match because it's in the title of the application. I don't know how the weightings work, but I hope it can be fixed - 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. 

I use krunner as quick starter for applications mainly, so I'd appreciate some refining on these cases, so that applications that are used very often (several times per session) are always the first entry.

By the way, in 90% of the cases krunner result order is excellent, I really like that applications come first most of the time! Good job on that one!

Best regards
Stephan
Comment 1 Alexander Lohnau 2022-12-16 18:15:32 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.
Comment 2 Natalie Clarius 2022-12-18 23:54:14 UTC
(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?
Comment 3 Alexander Lohnau 2022-12-22 16:42:46 UTC
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
Comment 4 stephan.leineweber 2023-04-18 19:49:02 UTC
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!