Bug 489866 - Krunner doesn't order search results based on my preferred order
Summary: Krunner doesn't order search results based on my preferred order
Status: RESOLVED FIXED
Alias: None
Product: krunner
Classification: Plasma
Component: general (show other bugs)
Version: 6.1.2
Platform: Arch Linux Linux
: HI normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 485881 488856 491237 494559 498383 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-07-07 11:31 UTC by elman
Modified: 2025-04-07 21:42 UTC (History)
22 users (show)

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


Attachments
wrong order of search results (67.87 KB, image/avif)
2024-07-07 11:31 UTC, elman
Details
Screenshot of Plasma Search settings with KRunner search results (362.34 KB, image/png)
2025-02-10 14:59 UTC, Rohit Bhute
Details

Note You need to log in before you can comment on or make changes to this bug.
Description elman 2024-07-07 11:31:26 UTC
Created attachment 171454 [details]
wrong order of search results

SUMMARY
When I open settings for Plasma search, I set my favourite plugins and set them in specific order. Then I run search in KRunner and my results are not in my preferred order. See screenshot. I believe it worked find in 6.0 series and got broken with upgrade to 6.1.

STEPS TO REPRODUCE
1. Add favourite plugins Windows, Applications, System Settings in that order.
2. Open KColorChooser
3. Open KRunner and search for "color"

OBSERVED RESULT
System settings are first, then Applications and then Windows.

EXPECTED RESULT
I should see Windows are first, then Applications and then System Settings.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 6.1.2
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.7-arch1-1 (64-bit)
Graphics Platform: Wayland
Comment 1 Kai Eckert 2024-08-02 13:58:33 UTC
I can confirm this bug. It sounds like a small thing, I would suspect that it got introduced in this commit: 

https://github.com/KDE/krunner/commit/d02e1c13a9ee92a90218a4584a3642f39da4e28a
Comment 2 cwo 2024-08-04 00:19:12 UTC
*** Bug 491237 has been marked as a duplicate of this bug. ***
Comment 3 fanzhuyifan 2024-08-09 17:58:21 UTC
IMO if users rank windows above applications, they *really* want the results of windows to be above applications
Comment 4 John Kizer 2025-01-13 20:15:01 UTC
*** Bug 494559 has been marked as a duplicate of this bug. ***
Comment 5 John Kizer 2025-01-13 20:21:12 UTC
*** Bug 498383 has been marked as a duplicate of this bug. ***
Comment 6 matterhorn103 2025-01-15 06:12:18 UTC
I can confirm this happens for me both on

Operating System: Fedora Linux 41
KDE Plasma Version: 6.2.5
KDE Frameworks Version: 6.9.0
Qt Version: 6.8.1
Kernel Version: 6.12.7-200.fc41.x86_64 (64-bit)

and on openSUSE Tumbleweed with the same versions of the KDE/Qt stuff.
Comment 7 matterhorn103 2025-01-15 06:15:49 UTC
Since no one else has noted it here yet – the effect seems to be that favourites appear in **precisely the reverse order** with respect to the user's choices.
Comment 8 John Kizer 2025-01-23 00:45:14 UTC
*** Bug 485881 has been marked as a duplicate of this bug. ***
Comment 9 John Kizer 2025-01-23 00:45:40 UTC
*** Bug 488856 has been marked as a duplicate of this bug. ***
Comment 10 Rohit Bhute 2025-02-10 14:59:18 UTC
Created attachment 178114 [details]
Screenshot of Plasma Search settings with KRunner search results

The order is not reversed preferred order.

STEPS TO REPRODUCE
1. Add favorite plugins Windows, Applications, File Search, System Settings in that order. No other plugins are enabled.
2. Open VS Code.
3. Open KRunner and search for "code"

OBSERVED RESULT
1. I see compressed files with name matching "code", Archives.
2. Then I see the VS Code Windows entry.
3. I see video files  with name matching "code", Videos.Then Spreadsheets, Documents, Folders.
4. Finally I see the Applications entry for VS Code.

EXPECTED RESULT
I should see Windows first, then Applications and then results from File Search.
Comment 11 Ben Opp 2025-02-10 15:32:45 UTC
I confirm previous comment, the problem is not that specific.
Order of search results I am observing is not the exact reverse of the one defined in Settings.
Let devs test out the exact nature of the mismatch.
Comment 12 Ben Opp 2025-02-10 15:36:08 UTC
I went ahead and restored the previous name.
Comment 13 Mathias Tillman 2025-02-28 10:35:44 UTC
Can confirm that the ordering seems to be a bit off, and that reverting the commit above (d02e1c13a9ee92a90218a4584a3642f39da4e28a) restores the old behaviour. It was introduced in the MR https://invent.kde.org/frameworks/krunner/-/merge_requests/168. I will ask the maintainer about the intended behaviour there.
Comment 14 Bug Janitor Service 2025-03-12 21:23:47 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/krunner/-/merge_requests/189
Comment 15 Nate Graham 2025-03-13 18:19:22 UTC
Git commit 62d61bef36c838c3ebc7ce291c481200d47cb1bc by Nate Graham.
Committed on 12/03/2025 at 21:10.
Pushed by ngraham into branch 'master'.

Revert "Give favorites a relative boost rather than absolute sorting position"

This reverts commit d02e1c13a9ee92a90218a4584a3642f39da4e28a. It
undermines the manual sorting feature by causing search result
ordering to not conform to the user's configured preference.

If the user wants results ordered in a particular way, KRunner should
always honor that.

If this leads to an unacceptable UX, then it means the manual ordering
feature itself is unworkable and should be removed instead.
FIXED-IN: 6.13

M  +4    -11   src/model/resultsmodel.cpp
M  +0    -1    src/model/resultsmodel.h
M  +1    -3    src/model/runnerresultsmodel.cpp

https://invent.kde.org/frameworks/krunner/-/commit/62d61bef36c838c3ebc7ce291c481200d47cb1bc