KRunner, the framework, is the backend behind the 'krunner' UI, as well as being used for search operations within the Plasma shell. Backends (or 'runners') are written as plugins, which can come from a range of sources and loaded by both the plasmashell and krunner process.
This works fine for simple tasks like calculators, dictionaries and listing applications. However, if we want to search through data that's available in an already running application, this approach isn't ideal.
What's changing
In addition to the current plugin structure, runners can have their results fetched from another process via DBus.
To work, apps supply a .desktop file with the DBus service name of a search provider. The apps then implements a couple of DBus methods to return a list of matches for a given search query, and another method called when a match is invoked. Depending on the situation, you might want to make this DBus-activatable, or just silently do nothing if the service is not running.
Example of a query being performed:
Results are presented identically.
Benefits:
Reduce code re-implementations
The original motivation for writing this was plasma-browser-integration writing a runner. Kai ended up writing both a DBus API on the client, and a runner to read from it. A common standard cuts that in half for any future apps wanting runners.
Memory saving
Instead of data being in 3 places: the app with the data, plasma shell and krunner, data is only stored in one place and then fetched by the two UIs.
Robustness
Plasma shell is a very core process. We want that to stay alive even if the included plugins fail. One of our more problematic runners was moved out of process to solve this in Plasma/5.11
Portability
By not being linked inside the same binary, we solve a lot of portability issues.
* I can make runners in python (example) or potentially any other language with no extra dependencies
* We'll be able to handle the ineviatible Qt6 changeover in a few years without runners having to all be ported at the same time.
This was a big problem for KTp, which had the main USP of having tight Plasma integration. We caused a big problem for ourselves resulting in a rushed port.
* It's a step towards next gen where more apps and services are sandboxed.
Conclusion
Hopefully this will improve Plasma and make it easier to write runners.
I hope to see runner support to kde-connect and search active konversation tabs. Personally, I'm already using the python support for custom code to talk to my home-automation server which had a python lib.
If this has inspired you to write a runner and documentation is unclear, ping me (d_ed) on #plasma.
Thanks for all the work. Any chance that Ivan Čukić’s KRunner improvements/ideas are going to be merged?
Quick google showed, http://cukic.co/2016/06/21/distributed-krunner-improvements/ ?
I haven’t seen anything in the past year… and I’ve not seen any code. It’s not me you need to be asking :/
There’s some ideas that are sensible, though the fact that it’s not retrofitting into the existing API is somewhat problematic.
This is awesome, I’ve been waiting for a simple way to write custom runners.
Are there already any ideas how to easily integrate new (community-) runners, e.g. via KDE Store/Get Hot New Stuff in the plugin dialog?
Otherwise, I’d need to run new runners on my own, right?
Ideas, yes
Implementations, not yet
This is great news! I have always believed Plasma and KRunner would be much more robust if extension points such as runners were running in separate processes.
In last 3 years I tried several times to implement custom runner and always failed because I found only scarce documentation, hit some roadblock and gave up after few hours. This time I finally succeeded. In one hour everything is running. Owesome! Thank you! 🙂
Is there some way to distribute this runner in standard way (KDE store)?
I had to remove ‘msg’ argument from Actions method because it complained that this attribute is unset. Otherwise the sample python app was working without problem.
For any beginner like me: To run the sample, execute the python script (it keeps running indefinitely), copy .desktop file to ~/.local/share/applications/, run kbuildsycoca5, killall krunner, start again krunner.
> Is there some way to distribute this runner in standard way (KDE store)?
Yes and no.
You can distibute any random files in the store.
There’s currently no system to install the python script and the desktop files to the right places. You’ll have to include instructions.
Including adding the python script to the user’s autostart dir.