| Summary: | Krunner results order is unintuitive and often deprioritize the obvious choice | ||
|---|---|---|---|
| Product: | [Plasma] krunner | Reporter: | Oded Arbel <oded> |
| Component: | general | Assignee: | Alexander Lohnau <alexander.lohnau> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 677ee1vp, alexander.lohnau, aoeui, bugseforuns, dashonwwIII, kdebugs, kishore96, natalie_clarius, nate |
| Priority: | NOR | Keywords: | usability |
| Version First Reported In: | 5.27.4 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | 6.0 | |
| Sentry Crash Report: | |||
| Attachments: |
1. search "todo"
2. Search "discover" 3. search "mobile" |
||
|
Description
Oded Arbel
2023-04-30 09:23:08 UTC
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. |