| Summary: | Two character searches return few or no results, in contrast to searches with one character or three or more characters | ||
|---|---|---|---|
| Product: | [Plasma] krunner | Reporter: | Antti Savolainen <antti.savo> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | 4wy78uwh, adam.m.fontenot+kde, alexander.lohnau, brandowlucas, coconetdu09, cwo.kde, i, kdedev, laichiaheng, larionenkoruslan, lingm+kdebugs, martial_vipers.2p, mikel5764, natalie_clarius, nate, noahadvs, tagwerk19, typingcat |
| Priority: | HI | Keywords: | regression, usability |
| Version First Reported In: | 6.1.3 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | Plasma 6.5 and Gear 25.12.0 | |
| Sentry Crash Report: | |||
|
Description
Antti Savolainen
2024-07-29 12:48:49 UTC
This applies to everything that is krunner-based (like kickoff, krunner itself, or the overview screen) so moving there. I'm pretty sure this is intentional - many of the search categories only apply from the third letter (and sometimes even more) on, to avoid completely irrelevant matches. But I guess the information presented could be a bit more informative to the user, conveying something to the effect of "type more to enable more search results". KRunner has a minimum character count of three. With fewer characters, matches are rarely any good, so we delay until there's a third character. Understandable. Cwo's suggestion to show a reason at least in kickoff sounds good. I'm not sure this is worth doing, or even feasible. We could only do it for Kickoff because that's the only place there's space, and even then, not all runners have this character minimum, so the results list would start to populate with items from some runners, consuming the space we would put a message in. I don't think we can do that, sorry. *** Bug 491334 has been marked as a duplicate of this bug. *** (In reply to cwo from comment #1) > I'm pretty sure this is intentional - many of the search categories only > apply from the third letter (and sometimes even more) on, to avoid > completely irrelevant matches. I don't get it. If it shows nothing for 2 letters because the search result is not good, why does it show result for 1 letter, which is even shorter? Also, I don't agree that 2-letter result is mostly useless. In my opinion, the better option is just order the results by the frequency. That is, if I had typed `wr` and choose "writer" often, then "writer" should be at the top when I typed `wr` next time. Doesn't Windows start menu search work that way? > I don't get it. If it shows nothing for 2 letters because the search result > is not good, why does it show result for 1 letter, which is even shorter? It does show a search result for two letters. Try it, type "Do" and you'll see Dolphin. "Ka" finds Kate. It only searches for things that *start* with these two letters though (or where a keyword starts with two letters, and I think it may be only applications and system settings pages, not also files and windows etc., but I'm not quite sure off the top of my head what exactly the parameters are). Many entries have lots of keywords that are there so people can find things under different names; searching everything with two letters already would often give so many results that it wouldn't be possible to select the correct one, and would likely appear to be just as incomprehensible to users as not finding anything. > In my opinion, > the better option is just order the results by the frequency. That is, if I > had typed `wr` and choose "writer" often, then "writer" should be at the top > when I typed `wr` next time. Doesn't Windows start menu search work that > way? As far as I know, krunner is already supposed to use frequency as one of the things to take into account; in any case, that would be a separate bug. (In reply to cwo from comment #7) So, you mean, it works for "Ka" because "Kate" starts with it, but not for "Wr" because "LibreOffice Writer" does not start with it? It would make sense not to include descriptions or other metadata, but in case of "LibreOffice Writer", I think that effectively its name is "Writer", because I don't think anyone would call it "LibreOffice Writer" under normal situations. I just call it "Writer". So, shouldn't the 2-letter search match the start of any word in the name? And about having too many results, maybe that is only the case when file search is enabled. I always disable it, because I kind of think it's dumb to search the file system in the start menu search. So, in my case, "wr" would only match a few items. In this case, can't the two-letter search not work for file search results, but work for application name search? (In reply to Sin Jeong-hun from comment #8) > It would make > sense not to include descriptions or other metadata, but in case of > "LibreOffice Writer", I think that effectively its name is "Writer", because > I don't think anyone would call it "LibreOffice Writer" under normal > situations. I just call it "Writer". So, shouldn't the 2-letter search match > the start of any word in the name? Maybe. Off the top of my head, this seems like a reasonable change, but I haven't seen the discussion that led to the current situation. See if that is already filed as a bug (maybe a closed one?) and if not, try submitting it. > And about having too many results, maybe that is only the case when file > search is enabled. I'm sitting on a Plasma 5.27 installation which is a bit more inclusive at two letters than 6 seems to be. If I search for "te" I get "TeXInfo", "Fonts", "Application Style" "Default Applications". "Night Color", "User Feedback", "Compositor", and "KDE Connect" as results. For most of there I have no idea why they would show up, though of course I could find out. And that doesn't include general key words and similar things; certainly not files. krunner can search through a lot of things, and will often find lots. *** Bug 491501 has been marked as a duplicate of this bug. *** My duplicate report had the following proposal for improving this, which I think is a good one although it doesn't really eliminate the need for better communication: For the two letter search, show all results that begin with those two letters, as before. *Also*, however, perform the same search for just the first letter. *Filter* these results with the two character string using the broader search patterns used for 3+ letters, and add anything that fits to the results displayed to the user. This would be relatively cheap, and have the advantage of solving what I think is the bigger issue here, the visual glitch of going from 1 to 2 to 3 letters. E.g. if I type "s", the top result is System Settings, which is in fact what I usually want. If I then type "e" I get no results, because there are no items beginning with "se" (despite "settings" beginning with "se"). If I type "t" I suddenly have suggestions again, and the top result is once again System Settings. This is weird because System Settings disappears after two letters even though I'm using what is probably the most sensible way of searching for it. If I happen to be typing rapidly and hit the enter key after two letters, nothing happens. With my proposal above, System Settings would *remain* the top result after "se". I also like the idea of splitting the words suggested above, so that "LibreOffice Writer" appears for "wr". So while this specific issue probably can't be fixed - you can't do the full search for < 3 characters without returning nonsense results, the heuristics could be improved so that this doesn't feel like such an obvious bug. *** Bug 492457 has been marked as a duplicate of this bug. *** Lots of duplicates; let's reconsider and see if there's anything we can do about this. Another example: I'd like a search for "vs" to show "Code - OSS". It does have the keyword "vscode" in its .desktop file, but those apparently only get searched starting with three letters. It will be nice to remove this 3 characters limit or make it customizable(at least via a config file). I think results are still relevant with 1 character because we have prioritization in search results(looks like recent or frequently used prioritization) Looks like Gnome Launcher search doesn't have a minimum character limit, and it works really good with prioritization, so KDE can do it too. *** Bug 504503 has been marked as a duplicate of this bug. *** Something I noticed which is contributing to the impact of this problem with the Search widget: * Unlike krunner, Search does not auto complete previous searches. When I type "se" into krunner, I get a complete set of results because it autocompletes a previous search. "se" in the Search widget shows nothing. * For some reason, searching in the Application Launcher widget is *much* faster than searching in the Search widget, despite the fact that they seem to (?) use the same search backend and have the same settings (and both show some file results). This is frustrating as Search seems like the simpler tool. This is a big enough difference that it's *very* easy to see: Application Launcher has search results available instantly before my fingers can even come off the keys, Search takes probably 0.4 seconds to show results. When you're already "waiting" for results because of this issue, another 0.4 seconds makes it feel much worse. Happy to report either / both of these as separate issues, but it's not clear to me that they are issues. Mentioning them here because I realized when trying out these other widgets today that this bug bothers me much less when using them than my usual search widget (Search). *** Bug 505968 has been marked as a duplicate of this bug. *** *** Bug 503323 has been marked as a duplicate of this bug. *** I dug into this a bit and came to the conclusion that the problem is KRunner's infrastructure for allowing individual runners to ask for a minimum letter count before they start returning results. Because runners choose different minimum letter counts, the problem is not solvable, and the best we can do is document it by changing the UI of each KRunner-powered search to be clearer about what's going on. But this is a poor result IMO. The whole thing is also not great for Chinese where 1 and 2 character searches could otherwise return useful results. IMO it's a contributor to KRunner's search results feeling awkward and random, and I'd consider it a failure and throw it in the bin. We could port all the runners away from using it, or even change setMinLetterCount() to always return 0 (or both). I experimented with that, and the search results seem… fine? For background information, the minimum letter count system was added in https://invent.kde.org/frameworks/krunner/-/merge_requests/26. Does that currently mean that for "Applications" some simplified fallback is used below 3? Because to the user it appears as if it was the same thing, but clearly the results are different (only 3+ search in app descriptions). So it would appear that, if I deduce correctly, it's not only because of varying minimum letter count on its own, but also because they vary what they are actually searching through based on said letter count within the runners themselves too? (and if so, I'd fully agree that's even more confusing then) So you're probably right that phasing out this system would be a good call. I mean why wouldn't I get to see a "qr.txt" file that I have if I search just for "qr", etc.? The only case where it sort-of could still make sense is cases like Calculator, where it shows nothing for just "=", but shows for "=1". But even then, I think the better UX would be if just "=" prompted Calculator runner and had it show some encouragement prompt like "Type out an equation to calculate its result" (that means that'd be a discoverable feature for someone who stumbles upon it by accidentally typing "=" too as a bonus (yes there is already the "=35.99+10.99" placeholder thing but still)) As for the background, eh, I think thread spawning prevention idea goes a short way there in the end, where indeed most queries users type in will likely be 3+ characters anyway, with these threads all spawning anyway, only with slightly bigger delay, unless the query is actually shorter, but then the results are borderline useless. Count it as a value-added advantage that if someone enters just "a" as a test of sorts, they see a whole bunch of results in all categories, meaning they'd get to see the power of KRunner and all its runners, right? And get to see in practice all the kinds of things they can search up with it. Win-win actually? The minimum character count is per runner, and the Applications runner has no minimum, which is why it starts to match text immediately. Most others have a minimum of 3, some are 2, and one other one I found (System Settings) also had no minimum. It might make sense to keep the ability of a runner to set a minimum number of characters, but just use it much more sparingly than we currently do. The calculator runner would be an example where a minimum character count of 2 makes sense (and in fact, it already sets that). A possibly relevant merge request was started @ https://invent.kde.org/documentation/develop-kde-org/-/merge_requests/664 A possibly relevant merge request was started @ https://invent.kde.org/frameworks/krunner/-/merge_requests/200 A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5721 A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7962 A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin-x11/-/merge_requests/64 A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-browser-integration/-/merge_requests/162 A possibly relevant merge request was started @ https://invent.kde.org/utilities/kclock/-/merge_requests/223 A possibly relevant merge request was started @ https://invent.kde.org/network/neochat/-/merge_requests/2364 Git commit 185fbe963e62f264c426c848c218ce727769e5b7 by Nate Graham. Committed on 01/08/2025 at 12:58. Pushed by ngraham into branch 'master'. kclock-runner: remove unnecessary minimum letter count Users generally expect search results to start appearing with the first character typed; we shouldn't be setting minimum letter counts without a very good reason. Excessive minimum letter counts are also bad specifically for Chinese, which is highly information-dense. Get rid of the minimum letter count. M +0 -1 kclock-runner.desktop https://invent.kde.org/utilities/kclock/-/commit/185fbe963e62f264c426c848c218ce727769e5b7 Git commit e2917dd80807577c15b4c36c71494e5f808cb381 by Nate Graham. Committed on 01/08/2025 at 19:07. Pushed by ngraham into branch 'master'. runners: reduce unnecessary usage of minimum letter counts Users generally expect search results to start appearing with the first character typed; we shouldn't be setting minimum letter counts without a very good reason. Excessive minimum letter counts are also bad specifically for Chinese, which is highly information-dense. Get rid of most of the minimum letter counts, and reduce from 3 to 2 in cases where this was done to prevent unnecessary DBus or Baloo queries, which can be more expensive. M +1 -1 runners/appstream/appstreamrunner.cpp M +1 -1 runners/baloo/plasma-runner-baloosearch.desktop M +0 -1 runners/bookmarks/bookmarksrunner.cpp M +0 -2 runners/places/placesrunner.cpp M +2 -3 runners/recentdocuments/recentdocuments.cpp M +0 -1 runners/recentdocuments/recentdocuments.h M +0 -1 runners/sessions/sessionrunner.cpp M +0 -1 runners/webshortcuts/webshortcutrunner.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/e2917dd80807577c15b4c36c71494e5f808cb381 Git commit 19fed4f415f7eeeb75a5dd784ad4aebf88d53934 by Nate Graham.
Committed on 02/08/2025 at 00:51.
Pushed by ngraham into branch 'master'.
Remove min letter count example
We don't want to encourage setting this too high, since it can result in
weird search results. Ideally you don't need to use it at all.
M +0 -2 templates/runner6/src/%{APPNAMELC}.cpp
https://invent.kde.org/frameworks/krunner/-/commit/19fed4f415f7eeeb75a5dd784ad4aebf88d53934
Git commit 90e70b92bba838abea48e650bf6c05e3355b7c26 by Nate Graham. Committed on 03/08/2025 at 15:02. Pushed by ngraham into branch 'master'. plugins/krunner-integration: remove unnecessary minimum letter count Users generally expect search results to start appearing with the first character typed; we shouldn't be setting minimum letter counts without a very good reason. Excessive minimum letter counts are also bad specifically for Chinese, which is highly information-dense. Get rid of the minimum letter count. M +0 -1 src/plugins/krunner-integration/kwin-runner-windows.desktop https://invent.kde.org/plasma/kwin-x11/-/commit/90e70b92bba838abea48e650bf6c05e3355b7c26 Git commit 55a2745cd1a646ab464209cbb30a96016742100a by Nate Graham. Committed on 03/08/2025 at 15:03. Pushed by ngraham into branch 'master'. plugins/krunner-integration: remove unnecessary minimum letter count Users generally expect search results to start appearing with the first character typed; we shouldn't be setting minimum letter counts without a very good reason. Excessive minimum letter counts are also bad specifically for Chinese, which is highly information-dense. Get rid of the minimum letter count. M +0 -1 src/plugins/krunner-integration/kwin-runner-windows.desktop https://invent.kde.org/plasma/kwin/-/commit/55a2745cd1a646ab464209cbb30a96016742100a Git commit 8457f6f7aa3fd5da6bc1ce020892c1c3f118321f by Nate Graham. Committed on 04/08/2025 at 14:33. Pushed by ngraham into branch 'master'. krunner plugins: remove unnecessary minimum letter counts Users generally expect search results to start appearing with the first character typed; we shouldn't be setting minimum letter counts without a very good reason. Excessive minimum letter counts are also bad specifically for Chinese, which is highly information-dense. Get rid of the minimum letter counts. M +1 -1 host/historyrunnerplugin.cpp M +0 -1 host/plasma-runner-browserhistory.desktop M +0 -1 host/plasma-runner-browsertabs.desktop M +1 -1 host/tabsrunnerplugin.cpp https://invent.kde.org/plasma/plasma-browser-integration/-/commit/8457f6f7aa3fd5da6bc1ce020892c1c3f118321f Git commit 1e9936a47288289c2db54f908686a3143f04eff4 by Nate Graham. Committed on 04/08/2025 at 15:25. Pushed by ngraham into branch 'master'. Refine recommendations for KRunner metadata docs Right now these docs are a bit unclear and don't discourage you from using the filtering features when they aren't necessary. As a resut, most runners out there seem to be using a minimum character count of three. This provides a problematix UX since not all runners do it, causing search results to change dramatically at the third character typed. The result is especially bad for Chinese, where every character encodes a lot of information. Rewrite this section to make it clear that you should only use these features with a reason, and don't recommend going above a minimum letter count of 2 without a very very specific good reason. M +13 -7 content/docs/plasma/krunner/metadata.md https://invent.kde.org/documentation/develop-kde-org/-/commit/1e9936a47288289c2db54f908686a3143f04eff4 Git commit b01286eae38540df943bdebbc197bc103f9cedf8 by Nate Graham. Committed on 04/08/2025 at 15:18. Pushed by ngraham into branch 'master'. plasma-runner-neochat: remove unnecessary minimum letter count Users generally expect search results to start appearing with the first character typed; we shouldn't be setting minimum letter counts without a very good reason. Excessive minimum letter counts are also bad specifically for Chinese, which is highly information-dense. Get rid of the minimum letter count. M +0 -1 src/app/plasma-runner-neochat.desktop https://invent.kde.org/network/neochat/-/commit/b01286eae38540df943bdebbc197bc103f9cedf8 That's everything. Now only two runners have a minimum character count before returning any results: 1. Calculator, since you can't have a mathematical expression with only one character. 2. Baloo/file search, since these queries are a bit heavy and a search through all your files for a single Latin character will definitely not return any sane results. So with these changes, you'll now see most search results start to appear after the first character typed, and then files will start to appear after the second one. This doesn't *perfectly* fix the bug in that one runner's worth of non-mathematical results will still appear later. However it's only two characters. I doubt anyone is really getting good results from one-character file searches anyway, at least with Latin languages. On that subject, a further enhancement I plan to work on is to make the universal minimum character count 2 for Latin characters and 1 for CJK languages, since their characters are more information-dense, so a single character search makes sense. This will make all runners behave consistently and start returning the same set of results at the same time (except for Calculator when using CJK languages for other things, where it doesn't mathematically make sense to do anything for a single character). *** Bug 508333 has been marked as a duplicate of this bug. *** Git commit 6926fc39c1b60d7a05abe0499be520130d029bad by Devin Lin, on behalf of Nate Graham. Committed on 14/09/2025 at 11:06. Pushed by devinlin into branch 'release/25.08'. kclock-runner: remove unnecessary minimum letter count Users generally expect search results to start appearing with the first character typed; we shouldn't be setting minimum letter counts without a very good reason. Excessive minimum letter counts are also bad specifically for Chinese, which is highly information-dense. Get rid of the minimum letter count. M +0 -1 kclock-runner.desktop https://invent.kde.org/utilities/kclock/-/commit/6926fc39c1b60d7a05abe0499be520130d029bad |