Bug 340283 - please add possibility to sort results returned by krunner by type
Summary: please add possibility to sort results returned by krunner by type
Status: CONFIRMED
Alias: None
Product: krunner
Classification: Plasma
Component: general (show other bugs)
Version: 5.0
Platform: Kubuntu Linux
: HI wishlist with 166 votes (vote)
Target Milestone: ---
Assignee: Alexander Lohnau
URL:
Keywords:
: 209519 269613 340491 357985 359627 359765 428541 431291 454633 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-10-24 08:03 UTC by Gandalf Lechner
Modified: 2022-12-08 23:59 UTC (History)
27 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gandalf Lechner 2014-10-24 08:03:47 UTC
This is a bug/wish related to krunner in plasma 5, please move it to a different spot if this is not the right place to report it.

It would be great if one could configure the order of the results displayed by krunner, e.g. bookmarks first, then apps, then local files, or something like that. I often get way to many local file hits and have to scroll down a lot before reaching the item I actually want. It would be even better if krunner would learn over time what the favourite items are (most often activated), and put these on top.

Reproducible: Always
Comment 1 Ruman Gerst 2014-10-26 13:12:00 UTC
Yes, that's very annoying! For example: If I want to start ksnapshot (no PrintScr-hotkey), I must type 'ksnapshot'. If I only type 'ksnap', files with that substring in name (or content) are top-priority. If I type 'ksnapshot', then it recognizes the program.
Comment 2 Vishesh Handa 2014-10-30 10:47:47 UTC
I've improved the automatic sorting to a large extent for Plasma 5.2, and it should remember your selections better. But there is still scope for improvement. Plus an explicit configuration might just be a good idea.
Comment 3 Vishesh Handa 2015-02-18 17:08:54 UTC
*** Bug 209519 has been marked as a duplicate of this bug. ***
Comment 4 Max Schettler 2016-06-17 15:12:04 UTC
*** Bug 359765 has been marked as a duplicate of this bug. ***
Comment 5 Brian 2018-08-10 22:17:41 UTC
If there were the ability to sort the plugins list (instead of being alphabetically sorted) then that should do it.  I don't remember what launcher that I've used before did this, but it was a nice simple way to sort plugin priority.
Comment 6 Carlos Pinzón 2020-01-28 05:17:53 UTC
*** This bug has been confirmed by popular vote. ***
Comment 7 Alexander Lohnau 2020-06-14 16:36:11 UTC
I wished myself this feature for quite some time too, but disabling some runners worked for me so far.

Also for context: https://phabricator.kde.org/R112:c2ea48d50fdaf9fa6260530e1a2eec35fb23184c

And I currently have no idea on how to design/implement this. Currently the sorting  priority is set in the KRunner plugins.
IMO adding a sort functionality to the plugin list feels also out of place.

If anyone has ideas feel free to comment.
Comment 8 Alexander Lohnau 2020-06-15 17:44:50 UTC
Maybe adding this as just a config key in the ~/.config/krunnerrc file?
Then the implementation would be pretty easy.

Similar to the font size trick mentioned in BUG 422567.
Comment 9 Alexander Lohnau 2020-06-19 17:30:08 UTC
@ngraham What do you think? Is this a feature worth implementing for "KRunner powerusers" or too a niche usecase?
Comment 10 Nate Graham 2020-06-19 17:51:24 UTC
Definitely worth implementing IMO. I've wanted this for years.

For comparison, macOS's equivalent feature (Spotlight) has custom sort ordering as its *only* user-facing configurable option, so I think it's definitely not a niche, power-user-only thing.
Comment 11 Alexander Lohnau 2020-06-30 17:34:14 UTC
*** Bug 359627 has been marked as a duplicate of this bug. ***
Comment 12 Alexander Lohnau 2020-07-08 10:46:28 UTC
*** Bug 340491 has been marked as a duplicate of this bug. ***
Comment 13 Alexander Lohnau 2020-07-08 11:33:16 UTC
*** Bug 269613 has been marked as a duplicate of this bug. ***
Comment 14 Alexander Lohnau 2020-11-01 08:03:42 UTC
*** Bug 428541 has been marked as a duplicate of this bug. ***
Comment 15 Nate Graham 2021-01-08 20:16:54 UTC
*** Bug 431291 has been marked as a duplicate of this bug. ***
Comment 16 Renan Inácio 2021-10-17 03:36:03 UTC
I use krunner a lot for simple calculations and then pressing [enter] to copy the result, but when using decimals (dot) and division (slash) it prioritize the Location plugin. So for an input like "123.4/5", the first choice is "https://123.0.0.4/5", which is a very inconvenient choice to press [enter] by reflex. The only work around I found was disabling the Location plugin.

krunner 5.22.5 (Ubuntu 21.04)
Comment 17 Alexander Lohnau 2021-10-20 16:04:21 UTC
(In reply to Renan Inácio from comment #16)
>The only work around I found was disabling the
> Location plugin.

You could also type =123.4/5 to make sure it is not interpreted as a URL.

I guess this is a documentation issue too, I made https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1102 which will hopefully make this more discoverable
Comment 18 GreggB 2022-02-24 14:37:50 UTC
As well as being able to prioritize Krunner results by plugin, I'd also like to have different plugin sets and plugin orders based upon whether Krunner was invoked directly (Alt-F2) or from within Kickoff.

I realize this is a big ask. And given that it adds possible complication and confusion for the user, the ability to split the Krunner configuration should probably be optional.
Comment 19 Natalie Clarius 2022-04-26 15:46:42 UTC
(In reply to Alexander Lohnau from comment #17)
> You could also type =123.4/5 to make sure it is not interpreted as a URL.

The same problem occurs for other kinds of queries too; e.g. typing 'config.md' always shows the (non-existent) location https://config.md as the first suggestion and the actual file `config.md` second, and this has no workaround as far as I know.
Comment 20 Natalie Clarius 2022-04-27 04:14:03 UTC
As for how to implement this without having to completely rewrite the KRunner logic considering that currently each plugin decides itself how important its results are: Would a possibility be to multiply the relevance values communicated by the plugins with a per-plugin relevance value configured by the user? Say files and system settings both have an applicable match but system settings ranks its results lower, and the user set KCMs to have the highest priority and files lower, then the KCM result would be taken over with its relevance unchanged, but the file result ranked down to 0.9 or so of its original relevance as the plugin ranks second in the global user configuration, and could thereby be outscored by the other category. Or something more sophisticated, but along those lines as a start?
Comment 21 GreggB 2022-04-28 12:55:32 UTC
(In reply to Natalie Clarius from comment #20)
> Would a possibility be to multiply the relevance
> values communicated by the plugins with a per-plugin relevance value
> configured by the user? 

This would be a step in the right direction. It would give the user some control over ranking. Is it not possible to totally override the plugin's value with one supplied by the user?
Comment 22 Natalie Clarius 2022-04-28 13:47:04 UTC
(In reply to GreggB from comment #21)
> (In reply to Natalie Clarius from comment #20)
> > Would a possibility be to multiply the relevance
> > values communicated by the plugins with a per-plugin relevance value
> > configured by the user? 
> 
> This would be a step in the right direction. It would give the user some
> control over ranking. Is it not possible to totally override the plugin's
> value with one supplied by the user?

No, because that would destroy the relevance ranking of the results within a plugin. The plugins give KRunner one absolute relevance value per search result; there is no distinction between the relevance of a plugin and the relevance of a match for that plugin.
Comment 23 Alexander Lohnau 2022-04-28 15:11:40 UTC
>Would a possibility be to multiply the relevance values communicated by the plugins with a per-plugin relevance value configured by the user?

Sth. like this is definitely possible. In the KRunner model we in fact differ from the relevance in certain scenarios (like the one match contains the query text and the other does not). Though this feels like a hack to work around the baloo runner being more relevant than it should be IMHO.

With parts of the KRunner UI being ported to QML, I am planning to work on this during the weekend or during the next week.
Comment 24 Natalie Clarius 2022-04-29 14:07:10 UTC
Looking forward!

How would the UI for such a configurable sorting work? The most flexible would be to let the user assign arbitrary numbers as weights in the plugin list, but this is perhaps confusing? So a simple drag-and-drop ordering with the relevance decreasing in steps of 5% or so?
Comment 25 Alexander Lohnau 2022-04-30 08:30:03 UTC
>So a simple drag-and-drop ordering with the relevance decreasing in steps of 5% or so?

Yeah, having the relevance in such percentual steps is what I had in mind.

Thinking about  this a bit more, there are some things that need doing first:

- Port the Plasmasearch KCM to QML, because otherwise we need to redo the UI the port happens 
- Fix the milou workaround I mentioned
- Ensure that the relevance stays in it's boundaries (only checked in one of two possible codepaths)
- Ensure that the logic to increase the relevance does not interfere too much with the sorting the user has specified. https://phabricator.kde.org/T13989 touches this topic
Comment 26 GreggB 2022-04-30 11:31:30 UTC
(In reply to Alexander Lohnau from comment #25)
> >So a simple drag-and-drop ordering with the relevance decreasing in steps of 5% or so?

While dragging the plugins around would be the ideal solution, I don't think that it is appropriate for this change. Given the underlying mechanism, I think it poses a number of problems.

Firstly, re-ordering the plugins creates the expectation that the results will be similarly re-ordered. The fact that it will not, creates its own confusion for the user.

Secondly, it denies the user the ability to adjust the weightings according to their needs. e.g. 100% to plugin A, 10% to plugin B and 50% to the rest.

It is problematic for me because it hides from the user what they are really doing. I think a 1-10 weighting on each plugin with the default set to 5 (or 10?) would be better. A tooltip could give a brief explanation of what the field adjusts.
Comment 27 Alexander Lohnau 2022-05-02 04:08:49 UTC
I will makeq a mockup before implementing the UI where I will consult the VDG and add it as an attachment to this bug report.
Comment 28 Gerion 2022-05-18 06:42:11 UTC
I just read the config.md example. Maybe it would also be a good idea to be able to delete (or downvote) specific search results. So, hovering above a search results makes a trashcan appear in the right corner and clicking on it just throw away this specific search result.
Comment 29 Alexander Lohnau 2022-05-19 06:25:16 UTC
>above a search results makes a trashcan appear in the right corner and clicking on it just throw away this specific search result.

If you mean that only for the recent documents runner I agree. Could you please file a separate feature request for it?
Comment 30 Alexander Lohnau 2022-05-24 16:45:52 UTC
>- Ensure that the relevance stays in it's boundaries (only checked in one of two possible codepaths)

We actually have in QueryMatch::setRelevance code that handles this.

the milou and KCM parts are currently in review.
Comment 31 Natalie Clarius 2022-05-30 15:09:32 UTC
(In reply to Alexander Lohnau from comment #29)
> >above a search results makes a trashcan appear in the right corner and clicking on it just throw away this specific search result.
> 
> If you mean that only for the recent documents runner I agree. 

Why only for the recent documents runner and not KRunner globally?
Comment 32 Bacteria 2022-05-31 06:43:47 UTC
*** Bug 454633 has been marked as a duplicate of this bug. ***
Comment 33 David Edmundson 2022-05-31 08:43:45 UTC
>For comparison, macOS's equivalent feature (Spotlight) 

Based purely on screenshots we have fixed user-set defaults for runner ordering, then the match relevance only acts within that.

That's doable as there's only one source of truth for everything. I would really strongly advise against going down a path of having the user adjust a weighting factor within Match::setRelevance. It'll overcomplicate everything in a way that makes life harder for us and users.
Comment 34 Nate Graham 2022-06-01 16:48:20 UTC
(In reply to David Edmundson from comment #33)
> That's doable as there's only one source of truth for everything. I would
> really strongly advise against going down a path of having the user adjust a
> weighting factor within Match::setRelevance. It'll overcomplicate everything
> in a way that makes life harder for us and users.

I would agree. Letting the user adjust group ordering but having KRunner determine ordering within groups makes sense to me.
Comment 35 Alexander Lohnau 2022-06-02 16:13:55 UTC
>I would agree. Letting the user adjust group ordering but having KRunner determine ordering within groups makes sense to me.

Yes that is the plan. Though I would allow configuring it on a per-runner basis.  A runner might have multiple categories (for example the baloo runner has Text, Documents and Archive), but having configurability for that is technically more difficult and IMHO overkill :)
Comment 36 Nate Graham 2022-06-25 16:09:18 UTC
*** Bug 357985 has been marked as a duplicate of this bug. ***
Comment 37 Natalie Clarius 2022-10-04 18:46:16 UTC
(In reply to Natalie Clarius from comment #19)

> The same problem occurs for other kinds of queries too; e.g. typing
> 'config.md' always shows the (non-existent) location https://config.md as
> the first suggestion and the actual file `config.md` second, and this has no
> workaround as far as I know.

This is now being addressed in https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2177
Comment 38 Martin Steigerwald 2022-10-04 19:47:39 UTC
Great. Thank you very much, Natalie!
Comment 39 Natalie Clarius 2022-10-27 00:22:13 UTC
The more I'm working with runner code the more I think there is potential to make things better besides (instead of or in addition to) introducing yet another source of truth to ranking. Apart from my MRs to make the assignment of match types more balaned between runners, here is a new suggestion:

KRunner already manipulates the relevance value, boosting frequently launched results. Move that logic into Milou, where all the rest of the sorting happens anyway, so that then instead of the relevance value (which is only used as a secondary sorting parameter and can never beat a higher match type) it can be made to affect the global ranking. 

And do something similar for categories, i.e. with each result launch keep a record of its category and use it to boost the rank of the category in the final sorting similar to the multiplier proposed for manual sorting, so that Milou will eventually learn user's preferences on its own.

How feasible do you think this is, Alex?
Comment 40 Nate Graham 2022-10-31 16:16:40 UTC
Git commit 1c8d9ee9a2691aebf79cbf261a66b272ebf95241 by Nate Graham, on behalf of Natalie Clarius.
Committed on 31/10/2022 at 15:51.
Pushed by ngraham into branch 'master'.

runners/locations: decrease match type when not a known existing file

M  +1    -1    runners/locations/locationrunner.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/1c8d9ee9a2691aebf79cbf261a66b272ebf95241
Comment 41 Nate Graham 2022-10-31 16:19:32 UTC
Git commit 80d9f1c8e5e816c7f2ff5464379a94d177652191 by Nate Graham, on behalf of Natalie Clarius.
Committed on 31/10/2022 at 16:19.
Pushed by ngraham into branch 'Plasma/5.26'.

runners/locations: decrease match type when not a known existing file


(cherry picked from commit 1c8d9ee9a2691aebf79cbf261a66b272ebf95241)

M  +1    -1    runners/locations/locationrunner.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/80d9f1c8e5e816c7f2ff5464379a94d177652191
Comment 42 Martin Steigerwald 2022-11-03 22:33:25 UTC
Thank you, Natalie and Nate.
Comment 43 Peter Hoeg 2022-12-05 02:27:43 UTC
All the hard work that goes into making the krunner and thus the returned results better help of course. But that doesn't change the fact that having the option to say "I don't give a hoot what krunner thinks I want or what I have clicked in the the past - I want applications to be returned first followed by local files no matter what" would be incredibly helpful.
Comment 44 Martin Steigerwald 2022-12-05 10:42:51 UTC
(In reply to Peter Hoeg from comment #43)
> "I want applications to be returned first followed by local files no matter what"
> would be incredibly helpful.

Seconded. I often enough ended up with Dolphin opening with a certain directory or kwrite opening some text file instead of the application I wanted to open, cause KRunner puts recently opened files before applications in search results. At least most of the time. For me this is the most annoying behavior of KRunner at the moment.
Comment 45 Natalie Clarius 2022-12-05 11:34:45 UTC
(In reply to Martin Steigerwald from comment #44)
> (In reply to Peter Hoeg from comment #43)
> I often enough ended up with Dolphin opening with a certain
> directory or kwrite opening some text file instead of the application I
> wanted to open, cause KRunner puts recently opened files before applications
> in search results. 

Which queries and search results exactly does this happen with? What do you type and what is the top result? Exact application matches should always be ranked highest.
Comment 46 Martin Steigerwald 2022-12-05 13:48:31 UTC
(In reply to Natalie Clarius from comment #45)
> Which queries and search results exactly does this happen with? What do you
> type and what is the top result? Exact application matches should always be
> ranked highest.

Well for privacy reasons I do not like to disclose any exact queries and search results.

What do you mean by exact application matches? Typing the whole application name? Well that would not be what I am interested in. One of my main uses of KRunner is starting applications. And it goes like this: Alt-Space, f => Firefox, Enter. This works with many applications but it does not work with others. For Telegram for example I have two local directories first in search results, one of them being "~/Downloads/Telegram Desktop" even though I rarely access that folder. I did access that folder recently, so it is in recent files. However, I do start Telegram several times a day, cause I do not leave it running all the time. So even when it goes by number of queries to determine search order it is wrong. I even had it not working with Firefox at one time. I really like to have applications first under all circumstances. Even when I only type part of the application name. Cause that is what I do most of the time. Of course I also search for files, but usually those are not named like applications. So KRunner could easily discern. When I start searching for an application name, in 99% of the cases I like to start the application and not access a folder with the application name in its name. So the order that works best for me is: First applications. And then at some point recently used files. Never ever the other way around.

This is with Plasma Workspace 4:5.26.4.1-1 on KF5 5.100.0-1 on Devuan Ceres.
Comment 47 Peter Hoeg 2022-12-05 14:03:33 UTC
> best for me is: First applications. And then at some point 
> recently used files. Never ever the other way around. 

This is exactly my experience/wish as well. 

And even if I have a partial match on an application, I would rather have that as the first option compared to an exact match for anything else.
Going further down the line, I would also like a partial match for a file before an exact match for a browser tab as an example. 

krunner has become smarter over the years, but I quite frankly don’t really need it to be smart. Just follow an order/priority I specify. And other people are of course very likely to have different priorities.
Comment 48 Natalie Clarius 2022-12-08 00:53:03 UTC
Thanks for the info. Yes, by "exact match" I mean typing the full name. Quickly opening an application by typing part of its name and always wanting certain categories first seems like a reasonable use case.   

I still think that extending the logic of boosting the relevance of frequently launched to pushing the ranking of a category as a whole would solve this use case while keeping it simple both UX and code wise;  but I'd like to her Alex' opinion on this first.
Comment 49 Peter Hoeg 2022-12-08 03:56:27 UTC
> I still think that extending the logic of boosting the relevance of frequently
> launched to pushing the ranking of a category as a whole would solve this use case

There are other use cases that it will not address so maybe we should try to map out the use cases first?

1. Because I use krunner as the main application launcher, I want applications to show first no matter what,

2. I rarely open a directory from krunner, but often open files, so I want a partial file match to show before an exact folder match. Frequency of use of the file doesn’t matter - it’s always files before folders.

3. I have had to disable the “Command Line” plugin because it would often match short words and thus rise to the top, but it would be convenient to still have around if I had the option to always put it at the end of the result list.

4. I rarely use browser tab switcher but it’s nice enough to have around. But it often rises to the top despite me *very* rarely actually selecting a tab this way.

Please don’t misunderstand the “I want” part - I’m not demanding anything, just outlining the use-case.

And the thing is - these are all personal preferences so no amount of smarts is really going to be able to suit people’s individual preferences and workflows when we are talking about “I *always* want this to happen first, no exceptions”.

Lastly, can I just say that krunner in general is phenomenal. We are firmly in the “nice to have” territory when it comes to this feature request.
Comment 50 Martin Steigerwald 2022-12-08 09:51:19 UTC
Thanks Natalie and Peter for commenting. Peter, I agree with you. For example I often enough also open directories, so for me files first might not match my exact use case. As I understood setting your own preferences would be difficult to implement. I think I remember that the individual runners decide upon their priority themselves. So I'd also be grateful for just the applications first case working out of the box.

And agreed: KRunner is awesome. It is one of the most awesome parts of Plasma desktop. I never seen a runner that works as good as this one on any other desktop environment or operating system. So yeah, thank you to all the developers on the great work on it! There is an opportunity though to even make it even awesomely awesome. :)
Comment 51 Natalie Clarius 2022-12-08 23:59:49 UTC
> 2. I rarely open a directory from krunner, but often open files, so I want a partial file match to show before an exact folder match. Frequency of use of the file doesn’t matter - it’s always files before folders.

This won't be achievable with a custom ordering of runner plugins as files and folders are provided by the same plugin. It would be possible if one were to use adaptive relevance based on category names rather than plugins.

All your other points seem reasonable to have and possible to achieve as well.