After David’s post, I got a few mails asking whether this change has anything to do with the project I started last summer, so I decided to provide a small update.
My original plan was to ship a test version of Blade a few months after the project announcement, but that did not happen. The main reason was that there were some higher-priority things in Plasma I needed to work on, so I had to put this on hold a bit.
While the project is not yet made public, some important things have happened that moved it forward quite a bit.
First, a teaser
Before I start, a fancy screenshot is in order. The main UI is as dull as it was, but there is another UI:
If you are not sure what this is, this is not a fancy new Plasma theme. This is a screenshot from a phone (more precisely, a phone version of Sailfish OS in a virtual machine) connected and set to search applications on my main system.
The design
I have significantly simplified the design because the original one induced some communication overhead to allow any two nodes in the system to communicate with each other (regardless whether they are on the same system or not).
This was a cool feature, but I’ve realized that it is not needed here, and that it is not needed in most programs that I’d use a similar message-passing mechanism in.
The messages now have a strict flow and each node can send messages only to its designated listener(s).
The beast below
I’ve also replaced the serialization mechanism which used the Qt data stream proocol with the ProtoBuf library, and the Qt networking has been replaced by ZeroMQ (yes, I’ve changed my mind).
One great thing about these libraries (and one of the reasons I decided to replace the old stack with them) is that they have fully-functional bindings for any programming language imaginable – from Python and Java, to languages like Haskell, Erlang and Elixir.
This means that it will be possible to write any of the components in any language you want. If you want to use Python’s great numeric libraries to implement the calculator runner, or if you want to implement a Web UI in Haskell, you will be able to. No need to be limited only to languages that support Qt.
The future
I don’t have any plans to propose replacing KRunner’s current implementation with this anytime soon. As David mentioned in his post, this would be problematic because this is a reimplementation with a completely different API and everything.
The first milestone will be to create an alternative to KRunner that will have enough cool features for people to start using it instead of KRunner.
This is the same approach I took a long time ago with Lancelot. Be a conscious choice instead of being the default.
One of the things I'd love to see is a GUI/implementation that doesn't limit results to single lines only. The current approach makes some krunner plugins like the dictionary almost useless because all the text can't fit in. Maybe the plugins can serve a QML component or something. Anyways, keep up the great work. I'm looking forward to test this some day