As promised, an explanation.
This is the “Command Not Found” runner. For those of you who may not be familiar, command-not-found is a magical little command line tool that gets activated when the shell cannot find the binary you wish to launch. It has a database of binaries and package names, and can check to see which package contains the binary you tried to type. If it finds one, it tells you which package to install to get this binary.
But I find that I use KRunner for launching my stuff more often these days. On new installs, I instinctually go to KRunner and try to type in the name of my favorite app. But then I get nothing; realizing that this is a new install and I have yet to install this piece of software. I mumble, backspace, and type in the name of my favorite package manager. I then type in the name of the application I wanted (again) and mark it for installation.
…but wouldn’t it be nice if I didn’t have to? I don’t anymore, thanks to the Command Not Found runner. I was browsing the KDE brainstorm section of the KDE forums and saw this idea. I thought it was neat and actually feasible, so yesterday I sat down and hacked. By the end of the day, the installer/command not found runner was born!
Here’s how it works: Whenever KRunner cannot find an application via KService, the Command Not Found runner takes what you typed and tells the command-not-found utility to find which package has that program. If command-not-found finds anything, the runner returns a result. Click that result, and it starts qapt-batch, telling it to install that package. You just have to enter your password, and qapt-batch will do all the rest. Neat!
As an added bonus, if the runner detects that the program you are trying to run has a different name than the package it is in, it gives a nice, helpful little subtext that explains that the amarok package contains “amarokpkg”, even though the package isn’t named “amarokpkg”.
A few notes based on the comments my mysterious post last night introduced:
- This is not meant to replace traditional package management. It is just a little convenience feature that can only ever install things that aren’t installed. It will never do anything more than that package management-wise.
- Going back to the first point, it is (in general) a good thing that you have to know the exact name of the program to get this to show up. It limits the usecase of this service to those who forgot that they hadn’t installed $app yet, and will have a very small likelihood of showing up for somebody who is not trying to run $app. There would really be no reason to not enable this by default, especially since KRunner is somewhat of a hidden feature in the first place…
- The KRunner plugin can be turned off.
- It does not do any package management itself. It leaves the installation to a real batch installer program.
- If the user does not have the privileges to install packages, it will not show up.
At the moment, it only works on Debian-based systems, since it requires the Debian command-not-found program. Sorry ’bout that.😦 I just don’t see a way that this could be done in a cross-distro manner right now… It was simple to code, however, so it shouldn’t be too much trouble to make one for another distro, if you know how their command-not-found works (if they have one, of course)
Going back to the KDE Brainstorm post, it is definitely feasible to add this to Kickoff. It does require a one-line patch, however, so that pretty much limits it to people who want to patch kickoff themselves to get the runner to show results there… It would be neat if we could make certain “categories” of runners, and then have kickoff configured to only show the results of certain categories. At the moment there’s a whitelist that you have to add to before they’ll show.
I’ll try to get packages up in the next few days, but due to my impending vacation I don’t know how successful I’ll be in actually getting around to it. You can grab the source here if you want to. It should just need kdelibs5-dev to build.
Posted by Jonathan Thomas 
