KRunner is one of the rare areas
of Plasma that have been mostly stagnating since 4.x,
and is one of the rare parts of Plasma that are still known to crash.
At least, the UI has improved in the last few releases thanks to Kai
who rightfully became the new KRunner maintainer.
Now, while the UI is still getting some love,
the backend is mostly not.
During the course of Plasma 5.x development,
Aaron had a really great idea
(inspired by his newfound love of Erlang)
of creating a more mature infrastructure for KRunner
that would (among other things)
allow it never to block the UI while calculating the results.
this never got integrated into KRunner UI
for various reasons.
KRunner infrastructure now
KRunner is plugin-based.
When the user performs a search,
it loads the plugins and sends them the query data.
This allows it to be extended easily,
and it makes it one of the most advanced launchers
in the free world (and proprietary as well).
The downside is that the UI is not isolated
from the engine,
and the plugin loading and more advanced searching plugins (runners)
can slow the interface down,
and ruin the user experience.
Whats even more problematic,
a single misbehaving runner
(one that tries to run outside of the running track)
can bring the whole application down.
For this reason,
the application menus that use KRunner to power its search
usually white-list only the runners we consider safe.
KRunner - a new hope
One of the things I’ve been spending my time lately on
is a possible new infrastructure design for KRunner.
I took a couple of ideas that Aaron had
(I’m not fond of Erlang as a language,
but its communication model is unbeatable),
forgot some of the others,
and added a few of my own.
The idea is to make runners to be simple isolated nodes
in the system
that are just able to send and receive messages.
Most of them should not even need
to keep any internal state
they just need to be able to receive a request,
and send back the response.
The fact that they share nothing with each other,
and with the main application
means that they can all be running in a separate process,
or that different runners can be
grouped into a few different processes
based on their speed and stability.
They could even all live in the same process,
as long as they do not live in the same process as the UI.
This architecture will allow the crashy runners
to crash as much as they want,
the UI and the rest of the runners
will continue their journey uninterrupted.
Querying other computers on the network
The fact that components are isolated
and that they can live in separate processes,
while only being able to send messages
to each other
has one really neat implication:
They can even live on separate computers,
and the messages can be exchanged
through the local network.
This will allow the KRunner UI that lives
on one computer,
to return results from other computers as well.
While this is not really useful for most runners
(the calculator will calculate the same value
regardless of the system it is running on),
it would be really useful
for runners like Baloo or Recoll which
search the local file-system
for files containing the search phrase.
You’d be able to search for files on as many
systems as you desire.
the systems would need to be paired first
for privacy reasons
you will not be able to search through
other people’s data if they did not allow it.
I’ve been working on the lowest level of the stack
on the library that will allow easy creation
of isolated agents (or peers),
and allow a network-transparent message passing between them.
it works reasonably well,
the different instances of the system
are able to discover each other
either via KDNSSD framework,
or, if it fails as it often does,
via UDP broadcasts and by sharing the ‘contact information’
about other agents to the newly arrived one.
The cool thing is that none of the agents
actually know whether they are talking
to an agent from the same process,
from the same computer,
or from some other machine on the network.
Plans of mice and men
is this one going to be the new KRunner engine?
I hope so,
but it first needs to become mature enough
to even be considered as a replacement.
I’ll post progress updates from time to time,
and screenshots when I actually
manage to hack it into the KRunner UI. :)