https://bugs.kde.org/show_bug.cgi?id=490972
--- Comment #21 from Michał <[email protected]> --- 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? -- You are receiving this mail because: You are watching all bug changes.
