SUMMARY When correct full name/title matches are available, KRunner often deprioritize them and prioritize unintuitive (and likely bad) results. Here are a few examples (screenshots attached): 1. Searching for existing file "todo" (on the home folder) that is often opened, Krunner offers to install "devtodo" then a bunch of documents in deep folders (in various open source repositories that I have checked out) based on content search (not file name) and only then the recent file named "todo". 2. More weird "Installer" option when trying to type "Discover". I'm not sure what is the "Installer" search anyway (that is enabled by default) - it finds weird things and they are never actually installable. 3. Searching for the folder "mobile", Krunner prefers partial name results under the "Image" category (I'm not sure what search plugin that is) and in the "Folder" category de-prioritize the most likely candidate - `~/Documents/mobile` - in favor of a non-existing folder with a deep path (likely a stale result from baloo search - I checked that this entry exists in the baloo index that is obviously out of date), though it looks like krunner knows it doesn't exist as it doesn't have a proper icon. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 ADDITIONAL INFORMATION I think that krunner should have more heuristics for prioritizing likelier options. I suggest the following: 1. Always prioritize correct name matches, possibly with this set of rules: a. Prefer full text match to the search query, if available. b. Otherwise prefer full word-boundry match to the search query (i.e. "this test" should prefer "I love this test" over "this testing regime"). 2. File matches (including "recent files") should be ordered with exact file name matches first, partial matches later and finally content-only matches, and within each, give lower weights to files under longer path names. 3. Installer and software center offers should always be ordered last.
Created attachment 158556 [details] 1. search "todo"
Created attachment 158557 [details] 2. Search "discover"
Created attachment 158558 [details] 3. search "mobile"
The issue where non-existing files are shown in krunner results is actually bug #353874 - I'm assuming that once Baloo no longer returns results of deleted files, krunner will not show them. It is still a problem that krunner prefers the longer paths (of the deleted files) over the shorter and more obvious paths under `~/Documents`. Also, from looking at the icon shown for deleted files, it is obvious that krunner knows the file is not accessible and I feel there is an option for a workaround to bug #353874 - at least as for krunner search results - of hiding results for obviously inaccessible files.
I will look into those specific cases. In general, we discussed some API improvements to the KRunner sorting during the Plasma sprint which might help with this too.
Can you please provide the whole filenames for the issue in the second screenshot? Also, the description would be good to have. The full description will be shown when hovering over the elided description.
(In reply to Alexander Lohnau from comment #6) > Can you please provide the whole filenames for the issue in the second > screenshot? I'm not sure what "filenames" there would be for the "Installer" plugin - it definitely does not look like file names. When selecting either of the suggested options I get a QApt error message saying something like 'The package "or" has not been found among your software sources. Therefore, it cannot be installed'. Looking at the output of `dpkg -l`, the "6.8.0.105" entry looks to be referring to one (or some or all) of the mono packages from Ubuntu, but I can't say I understand what KRunner means by "contains disco" as none of the mono packages have that text in either the short or long package description. There is nothing on dpkg's list that is just called "or" or has "or" as a dash-delimited word. > Also, the description would be good to have. The full > description will be shown when hovering over the elided description. The description for the first Installer entry is just 'The "or" package contains disco' and for the second entry is 'The "6.8.0.105+dfsg-3.3" package contains disco'
>I'm not sure what "filenames" there would be for the "Installer" plugin - it definitely does not look like file names. I thought it was a result for a local file, but it is just an appstream result (Applications plugin). TBH I have no idea what is wrong. https://invent.kde.org/plasma/plasma-workspace/-/commit/ad0f0d129d0080d035fd483317f7120ba6953031 should be shipped with the version you have installed. This change should ensure that suggested applications are always at the bottom. This is the behavior I get locally. >but I can't say I understand what KRunner means by "contains disco" as none of the mono packages have that text in either the short or long package description We get the description from AppstreamQt directly and do not modify it. Random idea: What does Discover suggest when searching for "disco"?
BTW, the "todo" issue still troubles me, but not in krunner - in the app launcher menu (that I believe uses the same library for search results?) When typing "todo" on the app launcher, the first option is to launch Tokodon (the Mastodon client) and only the second option is to open the "todo" file in the home directory. "Tokodon" doesn't even have the text "todo" in its name. Its probably latching on the text "masTODOn" in the description - which is really weird that a substring match of a comment scores better than an exact match on a file name.
Should this be closed now that you can sort results however you like in plasma6
Probably. Beyond that, probably what remains actionable would be *specific* individual cases of this for which we need new bug reports, one for each case.
(In reply to Nate Graham from comment #11) > Probably. A lot of the problems described in the reports were solved by Alexander Lohnau previous work, though the custom ordering does improve things further. > Beyond that, probably what remains actionable would be *specific* individual > cases of this for which we need new bug reports, one for each case. The main issue I still have is that "Files" and "Folders" search results are still pretty useless - it looks like a direct dump of baloo search results, in the same order they are returned from `baloosearch` - which seem to be ordered by the date the file was discovered by baloo, and because baloo is really bad at removing index entries after files are deleted and the KRunner search results are limited to 10 entries (for each plugin) - a lot of the time most, if not all, results are for files and folders that do not actually exist. I think the "Files" and "Folders" search plugins should either do better work at prioritizing useful results, or the baloo search API should be fixed. But we can indeed discuss these in other specific bug reports.