Hey all 
I would find KRunner a lot more useful if the kind of “trigger” words/phrase options available in plugins like Dictionary and Spell Checker, were available for more/all plugins. Presently I have a number of plugins disabled because I don’t want KRunner filled with false positives from multiple plugins when all I want to do is open an application.
For example, I could imagine assigning @file for the File Search plugin, @app for the Software Center plugin, etc.
+1
There’s already a similar functionality for the web search plugin, but it means that it depends on a specific plugin to implement. Would be neat if there was an option to assign a custom keyword to any plugins.
+1 to this.
Many plugins (including built-in ones) can be quite noisy in KRunner. While the framework technically supports prefixes, the responsibility currently lies with individual plugin developers to implement them. Transitioning this to a standardised, user-facing configuration would significantly improve usability.
The Problem:
Certain plugins return a high volume of results that drown out high-priority matches. Furthermore, users who take advantage of KRunner’s extensibility by enabling many plugins face a “diminishing returns” problem: the more plugins enabled, the harder it becomes to find any specific result due to the sheer volume of noise.
The Solution:
The most flexible approach would be a per-plugin trigger configuration within the KRunner settings. Instead of relying on individual developers to hard-code prefix logic, the framework should provide a universal “Trigger Keyword” field for every enabled plugin. This empowers users to decide which plugins remain “always-on” (like Applications) and which are hidden behind a prefix (like Spell Checker or Dictionary).
Current Workarounds:
Currently, the only ways to address this are to disable the plugin and assign it to an alternative hotkey, or to wrap the plugin in a custom script. Both are poor UX; the first fragments the “central search” experience, and the second requires technical knowledge that most users won’t have.
Alternative Considerations:
Simply limiting the number of results per plugin is not a robust solution. It often leads to cases where the intended result is hidden by an arbitrary cap. A framework-level trigger system is a more flexible, user-centric approach that ensures results are only seen when intentionally requested.
i like the idea of a UI for configurable prefixes that can apply to each type of search result
[settings|apps|bookmarks|file-types|etc].
it would enable me focus in on the results i wanted while at the same time allowing more plugins to be active, rather than having to turn them off or sort them among favorites.
+1 - customizable triggers (“direct activation command” in the docs, which I can’t link to presumably because my account is new), especially with single characters, is the nicest (only?) feature from PowerToys run that I’m missing in krunner.