Cross-process Runners

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.

  • Benjamin Traut

    Thanks for all the work. Any chance that Ivan Čukić’s KRunner improvements/ideas are going to be merged?

    • davidedmundson

      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.

  • Stefan Burnicki

    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?

    • davidedmundson

      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.