| Summary: | Desktop Session items require an exact text match now | ||
|---|---|---|---|
| Product: | [Plasma] krunner | Reporter: | Andrej <andrej> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | minor | CC: | adam.m.fontenot+kde, alexander.lohnau, natalie_clarius, nate |
| Priority: | NOR | Keywords: | regression, usability |
| Version: | 6.1.4 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Andrej
2024-08-11 06:17:19 UTC
> SOFTWARE/OS VERSIONS
>
> KDE Plasma Version: 6.4.1
Sorry, that should be 6.1.4
I can reproduce this. Are you saying that it was better in the past, that you were able to get to "restart" by typing fewer characters? (In reply to Nate Graham from comment #2) > Are you saying that it was better in the past, that you were able to get to > "restart" by typing fewer characters? That is part of it. The number one issue is that "restart" doesn't even show up until the full word is typed in. The second issue is the prioritization of suggestions. I would expect it to match more in line with what fzf does. The longest exact match must be at the top. Later you might add additional weights based on the frequency of use or something but that's not important. Maybe that's happening already but when the suggestions aren't being populated in the first place, the prioritization isn't noticeable. I will collect more examples of unexpected behavior and add to this ticket. > This is a regression that started a few versions ago. I seem to remember the same, though looking at the runner code I don't see how that could have been the case. Maybe you used to have auto-complete enabled on your KRunner history, and now that's turned off? If e.g. "restart" were auto-completing, you would have seen that result without typing the whole thing in. (Also if you're searching through the start menu or the search widget, those don't have history search any more, if they ever did.) In any case, changing the session runner code to match on `startsWith` instead of an exact text match yields good results for me, but I'm not sure if it's i18n friendly. > The second issue is the prioritization of suggestions. I would expect > it to match more in line with what fzf does. The longest exact match > must be at the top. Later you might add additional weights based on > the frequency of use or something but that's not important. I think the issue with this is that KRunner groups results logically by section, e.g. Applications, System Settings, etc, which makes sense because they're very different sorts of results. When weird results show up it's usually because a full search includes the descriptions and keywords of the .desktop files, e.g. Dolphin is an unfortunate partial match with "network shaRES". Which, yes, is really stupid, but it's hard to see how you would avoid it and still return all relevant results. If someone *is* looking for network shares, you probably do want to show Dolphin as an option. Reasonable proposals for improving the search heuristics are needed I think. E.g. maybe it makes sense to do some kind of word splitting on hidden values like the contents of desktop files, and only match the beginnings of words. So for example in this case Dolphin would only be shown if you typed e.g. "netw..." or "sha...". But even this is frequently going to be unsatisfactory, e.g. searching "abo" on this system (which I do multiple times a week, to get to "About this System") shows "ICC Profile Info" as an application suggestion. This program has a desktop file that contains the comment "Shows information about an ICC profile". So realistically to make this robust you have to get into word scoring - what's a *significant* search term? Network? Probably significant. About? Definitely not significant, only show direct text matches, nothing hidden. And none of this solves the problem of ordering, and I don't have a good solution there. Sure it makes sense for the longest exact match to be at the top, but you have to account for priorities of multiple logical sections. If you've typed in three letters and there are good partial matches from 5 sections, but Applications has 10 partial matches and one exact match, do you show *all* the applications above the other sections, even though most of them are crappy matches based on .desktop files? There's an ongoing discussion about this at https://invent.kde.org/frameworks/krunner/-/issues/2 where it might make sense to plug any good ideas. *** This bug has been marked as a duplicate of bug 474981 *** |