Similar to Bug 511235 which is about substring matches anchored to the beginning of the string; this one is about substring matches that are somewhere in the middle of the string (which should have a lower score than beginning-anchored substring matches). For example, searching for "code", I get the following results: - Discover (a fuzzy match) - Welcome Center (not sure lol) - Visual Studio Code - Prusa GCode Viewer - Kate - PrusaSlicer The first entry should be either Visual Studio Code or Prusa GCode Viewer (ideally the former).
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