| Summary: | Substring matches for name or caption in the middle of the string are outscored by inexact fuzzy matches | ||
|---|---|---|---|
| Product: | [Plasma] krunner | Reporter: | Nate Graham <nate> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexander.lohnau, kdedev, natalie_clarius |
| Priority: | HI | Keywords: | regression, usability |
| Version First Reported In: | 6.5.0 | ||
| Target Milestone: | --- | ||
| Platform: | KDE Linux | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=511235 https://bugs.kde.org/show_bug.cgi?id=511078 |
||
| Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/-/commit/8cf3a4ff92f007eef1c555cace8dd89a5498d12f | Version Fixed/Implemented In: | 6.5.2 |
| Sentry Crash Report: | |||
|
Description
Nate Graham
2025-10-27 19:38:48 UTC
On my machine with git-master I see these when searching for "code", where only VSCodium is where I'd expect The results are the same in Application Launcher fwiw - VSCodium - Discover (a fuzzy match) - Welcome Center (not sure either) - Visual Studio Code - Simple Screen Recorder - Satisfactory modeler - Handbrake A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5943 Git commit e7b91993dfff0214669b7f4f802c5c4ee5b4a30f by Harald Sitter. Committed on 31/10/2025 at 12:33. Pushed by sitter into branch 'master'. servicerunner: aggressively expand scoring system the previous bonus system wasn't producing very good results when perfect matches were involved. so, we now track perfect matches (along with the other properties of a match -- for future use) which allows us to more aggressively outline the base score we expect a good match to have with regards to relative order. at its heart this functions mostly the same. matching produces scorecards, scorecards are aggregated into weightedcards and those are then computed. the main difference is a new perfectMatchScore logic. if a match was perfect (required no substitutions) then we give it serious base line value relative to their weight. only after that we run the previous fuzzy scoring logic relying on bitap and levenshtein scores. the base score makes sure we have accurate ordering of perfect matches while the fuzzy score makes sure matches within the same base score are then sorted according to how fuzzy or distant they are Related: bug 511078, bug 511235 A +19 -0 runners/services/autotests/fixtures/org.gimp.GIMP.desktop M +2 -0 runners/services/autotests/fixtures/org.kde.konsole.desktop A +24 -0 runners/services/autotests/fixtures/org.libreoffice.LibreOffice.impress.desktop M +44 -2 runners/services/autotests/servicerunnertest.cpp M +35 -17 runners/services/servicerunner.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/e7b91993dfff0214669b7f4f802c5c4ee5b4a30f Git commit 8cf3a4ff92f007eef1c555cace8dd89a5498d12f by Harald Sitter. Committed on 31/10/2025 at 18:25. Pushed by sitter into branch 'master'. serivcerunner: don't complicated substitution scoring - if there is a distance: it's bad (cause it required fuzzying) - if not: it's good this gives us a more sizable difference between fuzzy and verbatim matches. also make sure to verify that in the vscode test M +0 -4 runners/services/autotests/bitaptest.cpp M +5 -0 runners/services/autotests/servicerunnertest.cpp M +1 -3 runners/services/bitap.h https://invent.kde.org/plasma/plasma-workspace/-/commit/8cf3a4ff92f007eef1c555cace8dd89a5498d12f |