Every time you search for the same term, the list of results is: - not sorted according to the sort order listed in the toolbar - sorted differently from the last time you ran the exactly the same search It should respect the current ordering, which by default is "Rating". I think this bug is responsible for a lot of persistent user frustration regarding Discover's search functionality.
Created attachment 115481 [details] Results not sorted by rating, even though the toolbar says they are
This is indeed a bug, but a different bug than it seems. Here we're trying to sort by search relevance, so if you search for "torrent" it would should first KTorrent than something like e.g. Krita because krita has something that says torrent in the description. Now this is possibly not working and it makes it rather hard to operate if stuff is coming from different backends (just mean First In, First Served), so it could make sense to just remove it. Or else, we add a "By relevance" item in the combo box when searching.
I don't like "Relevance" as a search criterion *anywhere* because it's meaningless. What does it mean for the system to think a result is more or less relevant? I have no way of knowing how its definition of relevance differs from my own. "Relevance" can work when the algorithm is *perfect*, but this requires years of telemetry to scrutinize how every search winds up for the user so that the relevance algorithm can be adjusted incrementally to reduce the amount of time it takes to acquire a result. Google literally spends billions of dollars on this. We don't have those resources, and even if we did we don't spy on our users so we will never be able to achieve the same results. Rating is IMHO a much better default sort order for search results.
I don't agree, but since your proposal is really easy to implement I'll go with it. :P I'll put it in master and we see how it feels.
Created attachment 115502 [details] torrent search without relevance Ugh, or not, this doesn't seem better.
Hmm, the problem there is that KNS entries are listed first because they're more highly rated. Perhaps this raises the question of whether searching across both apps and KNS ever makes sense. Whenever you do a search, you generally know the type of the thing you want to be returned; e.g. if you search for "torrent", you're expecting an app, and if you search for "wallpaper" you're expecting an KNS entry. Right now you have to deliberately navigate to the top-level category of the thing you want results resutned for before this will happen. Perhaps it would make sense to have searching on the main page default to searching only app backends, and KNS results would only appear if you navigate to an addons page.
The problem there is that sorting by rating upon search is wrong. We will have the same problem as soon as Wesnoth puts "torrent" in the description.
If sorting by rating is wrong, then the toolbar shouldn't falsely claim that that's what the search list is sorted by. Right now the control and the actual state are inconsistent. Regardless, we need to do *something* to clean up search results. This is currently a pain point.
Alright, then let's give this a go. I'll rename this bug to show when we're sorting by relevance, please if you find cases where what we're displaying is clearly wrong report so and we'll address it.
So this will add a "Relevance" entry to the sort order chooser? That's fine as long as you can actually use it to change the order too, and preferably it will remember the chosen order for all subsequent searches.
Git commit 5a01d44da1b08c2da5537bb5c48211b051b690db by Aleix Pol. Committed on 16/10/2018 at 00:29. Pushed by apol into branch 'Plasma/5.14'. Expose sort by relevance to the UI The menu isn't working at the moment when that's the case. M +1 -0 discover/qml/ApplicationsListPage.qml M +9 -1 libdiscover/resources/ResourcesProxyModel.cpp M +4 -0 libdiscover/resources/ResourcesProxyModel.h https://commits.kde.org/discover/5a01d44da1b08c2da5537bb5c48211b051b690db
The listing when searching for torrent is quite different today, 2019-01-14. Several entries with odd names on both pages.
*** Bug 414819 has been marked as a duplicate of this bug. ***
Created attachment 148265 [details] Screenshot: Exact Search term not on top of the list Can confirm that I also don't see any possibility to change the order of search result in Discover 5.24.4. Also I'd prefer if there are exact matches, to let them appear on top. Please see the screenshot.
Sligthly OT, forgive that, but while you have fingers in sorting feature, adding option to sort by package version would be very nice as requested in #456523.
I think it would be fair to let user to decide how does he want his search results to be sorted: - either by relevance - by rating - by name - by the number of downloads This crazyness of Google and Apple to not let users to sort the search results in their application stores must be gone. If you're either android or apple user, you should know it yourself, how little (actually none) controls you have over the search results. Doesn't that drive you crazy? So why to make the same bad decision? Sorry for being harsh, guys, but this searching / sorting topic is spanning for 4 years already without any real progress. And you can hear it from every place on internet, that newbies are discouaged from use "visual software package managers", because they suck. And this is one of the reason why.
Sorry for being annoying, but even if you stick to this option that results are sorted by relevance as they are coming from appstream, there's something wrong on the plasma-discoverer side either. When I search for "konq" with using appstreamcli, it gives me these top apps: ============= root@orangepi4-lts:~# appstreamcli search konq Identifier: org.kde.konquest.desktop [desktop-application] Name: Konquest Summary: Galactic Strategy Game Package: konquest Homepage: https://apps.kde.org/konquest Icon: konquest_konquest.png --- Identifier: org.kde.konqueror.desktop [desktop-application] Name: Konqueror Summary: KDE File Manager & Web Browser Homepage: https://www.konqueror.org .... ============= And it is nowhere near to what I see in the plasma-discover.
Created attachment 151456 [details] This is what I get from plasma-discover while searching for "konq". Compare it to the output of appstreamcli This is what I get from plasma-discover while searching for "konq". Compare it to the output of appstreamcli I gave above
Git commit 786243247a9b661c3fdc910df5cc8d5250267f1e by Marco Martin. Committed on 03/11/2023 at 16:51. Pushed by mart into branch 'master'. Relevance sorting heuristics for search Search also in appstreamId(): weird but only way to make gimp come up when searching for gimp, there is also appstream searchTokens but they are abused and lead to a lot of garbage results. Do a new sortRole default when there is a search. This relevance role combines: * rating * a measure based on The Levenshtein distance between search string and app name * an exact match with the name or a sub-word of the name It makes sortings much more "expected" than any of the other sortings. Related: bug 475844, bug 469026 FIXED-IN: 6.0  M +26 -2 discover/qml/ApplicationsListPage.qml M +6 -2 libdiscover/backends/FlatpakBackend/FlatpakBackend.cpp M +87 -38 libdiscover/resources/ResourcesProxyModel.cpp M +2 -10 libdiscover/resources/ResourcesProxyModel.h https://invent.kde.org/plasma/discover/-/commit/786243247a9b661c3fdc910df5cc8d5250267f1e