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. Unfortunately, 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. Nothing more. 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.
Naturally, 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.
Current status
So far, 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. So far, 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
Now, 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. :)
One thing that always thrilled me is the idea that physics today is quite similar to software bugs triaging. You have a currently (or previously) accepted theory, and you make experiments that will show that the reality sometimes does not work according to that theory.
That is essentially what happens at CERN and the CMS experiment. There were suspicions (theories) that the universe contains more types of particles than we supposed at some time. In order to show that, physicists decided to build a large particle collider and measure monitor for events that don’t fit the previously accepted theories.
Now, when these ‘bugs’ in the fabric of reality are found, the scientists do not try to fix them (you can’t change reality), but rather to make a mathematical model that describes the real world better than the last one.
Fixing bugs in Plasma
This is where software developers differ. We also try to make collisions which will expose problems in our software, but we are allowed to change the reality and fix the bugs instead of ‘just’ writing a new specification of our programs that includes the bugs as its essential parts.
My main task at the Plasma sprint we had in CERN was to actually perform as many collisions I can with the activity switcher, and fix all the bugs that I could find. Sometimes the collisions exposed issues outside the switcher – in other parts of Plasma.
I am glad that I can say that I’ve fixed quite a few issues where most were not previously known. Plasma 5.6 will have a more streamlined activity switcher than it used to because its back-end was completely revamped, and it will be much more stable thanks to all the bugs that went away.
Plasma is for scientists
We usually tend to cater to ordinary users, and computer geeks, and tend to get excited every time we see a computer screen with KDE software displayed on some popular TV show or a movie.
But I have to say that all these screenshots that many of us collected during the years fade a bit in comparison to seeing Plasma running on most computers in the control centre of the CMS experiment.
Some time ago, I saw that CERN people had their own clang tree with a few addons, most notable one being the C++ REPL (C++ interpreter) called cling.
Now we had a presentation by Pere Mato from CERN who talked about their ROOT data analysis framework. It seems like a really nice and powerful piece of software.
The software is around 50 million lines of code, mostly C++. Some of it is python, but it is only used for quick-and-dirty testing of new ideas.
Another cool thing is that they use Qt for writing UIs, and that they also run Linux and KDE Plasma.
Starting on Monday, the Swiss part of CERN will become a home to a dozen Plasma generators. Apart from that, it will also have to store quite a few VDG and W2L components.
We expect a few new developments in the Plasma research, including an improved miniaturization ray that can shrink it to small screens with improved efficiency, and improvements on the Wayland purification system which will provide a tearing-free environment for Plasma consumption.
All this would not be possible without people who support KDE. Please consider supporting us.
Published
in the Other section,
on 29 February 2016
For some time I used the Mirakel application to manage tasks on my phone and to synchronize it to the TaskWarrior on my main system. Unfortunately, Mirakel devs do not have the time to fix all the issues the application has with TW synchronization, so I’m unable to use it anymore. (yes, I could contribute to the app, but I’m not a fan of Android as a development platform)
I had to find an alternative - I needed just a one-way sync - to be able to create a note on the phone, and to have it pulled into TaskWarrior when I come home.
One of the (unfortunately not Free Software) services I’ve started using some time ago to collect clippings from the Web is Evernote. And it has a nice integration into Blackberry and Android.
I’ve decided to write a small script that pulls notes from Evernote that have a specific tag, and to put them into TaskWarrior.
The script does not have many features at the moment (it will get a few things more soon), but it works.
It can be found on github - https://github.com/ivan-cukic/taskwarrior-evernote