In the next release of Dolphin, the search backend (when Baloo indexing is disabled) will be faster and support more file types, by using external projects ripgrep-all and ripgrep to do the search. Merge Request
There are quite a lot to improve in Dolphin’s search (when not using Baloo). The content search should also search in file names. The search string is currently interpreted as a regular expression, but a fuzzy match or shell globbing seems to be a more sensible default (probably with regexp as an option). Hopefully future works will address these issues.
I agree here.
This is a super first step and many thanks but there’s a lot to do. There are many “simple traps” that can be avoided: You want to find that letter to Mary? As far as you remember it had “letter” and “mary” in the filename, you search for “letter mary” and you won’t find “letter-to-mary.docx” or “letter to mary.odt”
The work here has the opportunity to be the “rising tide that raises all boats”, fixes for the rga search should also be there for Dolphin’s own filenamesearch. Both could, if they can, get closer to the functionality that Baloo provides.
It’s awesome that you work on Dolphin and try to make things better! It’s a nice project with still plenty of places to go all out and make things even better!
Search included. You’re not the first one who tries to improve that and certainly won’t be the last one either. It’s an ever evolving and hairy subject that it’s never really done. Good of you to put in the time and try and make things better!
As you probably know, baloo has a long history and was once very actively and passionately being developed. Despite all it’s amazing features it still had many bug reports of which a large portion was related to CPU usage (don’t quote me on that, just out of memory). It wasn’t uncommon to get 100% cpu usage for the search indexer and thus subsequently get complaints about it.
That brings me to the subject you’re posting about. Ripgrep(-all) and dolphin. I think it’s safe to assume that people who disabled baloo/desktopsearch don’t expect something else to now all of a sudden kick in. Having it be “automatically enabled” when ripgrep is installed is, in my opinion, not the best way to go. Ripgrep, as far as i could find, has no affiliation with KDE/Plasma and people might just have it installed for other purposes. Those now get ripgrep powered search in Dolphin (provided baloo is turned off).
I don’t think that’s the right approach. I can see two possible approaches that are potentially better:
If you change the script to read “custom user scripts” then you get user configurable scriptable search options. That’s a win and great to have!
I would assume making it configurable (and not based on ripgrep being installed) would be a minimal requirement for shipping this in a next Dolphin version. Also, it might be interesting - when it does ship - to add some information about that in the kde first start window telling the user about the feature.
Just some things to think about 
Great work regardless, thank you!
Good to see one of the most critical functions in Plasma desktop being fixed, I hope this will resolve current bugs and get the same results returned by KFind.
The reason for not doing this: Using ripgrep is considered to be an implementation detail. The search results should be the same as in Dolphin’s internal search backend, and the only user-visible difference should be it’s faster.
So although we do have a way to skip ripgrep (modifying the script (as in the “Customization” part in the blog) to just exit 127 (command not found)), there’s no “user-friendly” setting for that.
What do you think could be the reason that people don’t want ripgrep being used in Dolphin?
Admittedly, not everything in the reasoning above applies to ripgrep-all, which does return more results than the internal search backend, due to supporting non-plain-text files.
As it should be! So nothing wrong there.
I don’t know why you think that would be the case. As far as i understand ripgrep it’s doing the search on the fly with no index being build. It should be far slower then anything with an index (baloo should be faster). If it’s not then there are bugs affecting it’s performance.
I don’t consider that a valid or usable way. That script you’re talking about will be overwritten when there’s a package update. Or there will be a conflict because of an edited file. These options worked for you during development because you had nothing updating the file “behind your back” besides you yourself. Now the distribution package manager is effectively controlling the file.
It’s also generally considered ill advised to modify system files. Go ask distributions what they think of it, they probably don’t recommend that approach.
The more proper route would be for the script to call some user-defined scripts. Just as an example from a completely different piece of software. Nginx. It loads /etc/nginx/nginx.conf and from within that file loads all the files in /etc/nginx/conf.d/*.conf (which are not part of the installer package).
You’re flipping the question.
Why would having ripgrep be installed all of a sudden affect how dolphin searches? To them this would be a question of: “huh, i disabled baloo, why does this search still use it?” As that’s exactly what’s happening.
You now essentially only give one real option of disabling it. Uninstalling ripgrep. That’s unrealistic as it has nothing to do with KDE, you’re merely using it.
The proper way, in my opinion, would’ve been to make a custom kioslave that can be enabled or disabled. Just like filenamesearch but not hacked into it.
I do want to remind you that not giving the option will cause you backlash sooner or later.
ihatethecashew which removed it. Eventually they provided an option to disable it.There’s many more areas where this happened, specifically when related to search. However good you think it is really doesn’t matter, there will be people just having none of it and wanting an option to disable it.
Don’t make the same mistake as your predecessors and give an actual way to disable ripgrep. To make it discoverable i’d put it in the File Search system settings as that’s where it makes sense to have it.
It doesn’t replace Baloo, as explained in the first sentence in the blog post.
That’s not the case, as explained in the “Customization” section in the blog post.
This won’t happen, as explained in the first sentence in the blog post.
I know, it’s a fallback of sorts. (baloo disabled + tools available = your new search mechanism)
You should make this very discoverable! Like on the wiki too. People should be able to google it and be led to a place that describes this (copying the script to a user folder)
Please read carefully what i said there. To the user it will seem like it will because it will now use your search mechanism in that case (again: baloo disabled + tools available = your new search mechanism). So yes, from a user perspective it will be: “huh, i disabled baloo, why does it still work” even though technically it uses ripgrep.
The real problem with Baloo and Dolphin internal searches is that they both fail to search for files, why not adopt the same search used by KFind?
So just as a general note: The huge advantage of using something like ripgrep is that we use a tool that people have worked on for many years to make it great. If we instead work on our own search backend just for Dolphin, we can assume that it will be worse than ripgrep unless we put in similar amounts of time to improve it as the ripgrep people already did. So we save development time and effort by reusing a battle-tested tool. Fixes can be done upstream so everyone benefits from them.
The real problem with Baloo and Dolphin internal searches is that they both fail to search for files
ripgrep is known to be very good at searching file contents. In that regard this seems to be a step in the right direction.
why not adopt the same search used by KFind
KFind is slower. We don’t need all the search options KFind has in Dolphin.
Why does what still work? If you mean search in Dolphin, then yes, it should, and did, and do still work, if you disabled Baloo.
Bear in mind that there will be instances where people depend on Baloo, a leading case being to get Tag Folders, and thus cannot disable it in order to use rg/rga search.
Two points…
I think System Settings > File Search is the “natural” location for a switch
For triaging, there needs to be a clear and simple way of seeing what is providing the search results. It’s one of the first steps when triaging, finding out “what is doing the searching here?”, it is not particularly easy at the moment with baloosearch and filenamesearch and it’s going to be more difficult if filenamesearch may use rg or may use rga,
People want to enable Baloo, but not to use it for search in Dolphin? Yes, IIRC there was an MR for such an option, and there were discussions in the search UI revamp issue to add a switch for that near the search box.
Agreed. It would be good that the user can see, or better, select the search provider in the search UI. I hope it could be addressed in the search UI revamp work.
For now, we have to run QT_LOGGING_RULES="kf.kio.workers.filenamesearch.debug=true" dolphin.
Example output when rg is used:
kf.kio.workers.filenamesearch: searchDirWithExternalTool dir: QUrl("file:///home/jin/tmp") pattern: "test"
kf.kio.workers.filenamesearch: Start "/home/jin/.local/share/kio_filenamesearch/kio-filenamesearch-grep" args: QList("--run", "test") in: "/home/jin/tmp"
kf.kio.workers.filenamesearch: Close STDIN.
kf.kio.workers.filenamesearch: "/home/jin/.local/share/kio_filenamesearch/kio-filenamesearch-grep" stopped. Exit code: 1
kf.kio.workers.filenamesearch: Search success.
And otherwise:
kf.kio.workers.filenamesearch: searchDirWithExternalTool dir: QUrl("file:///home/jin/tmp") pattern: "test"
kf.kio.workers.filenamesearch: Start "/home/jin/.local/share/kio_filenamesearch/kio-filenamesearch-grep" args: QList("--run", "test") in: "/home/jin/tmp"
kf.kio.workers.filenamesearch: Close STDIN.
kf.kio.workers.filenamesearch: "/home/jin/.local/share/kio_filenamesearch/kio-filenamesearch-grep" stopped. Exit code: 127
kf.kio.workers.filenamesearch: Search tool not found.
kf.kio.workers.filenamesearch: External tool not available. Fall back to KIO.
You’ll get no output when Baloo is used.
As I understand it…
Installing rg/rga will not “suddenly” change your search options. If you are using Baloo, you’ll continue to do so. if you have it disabled, you have been relying of Dolphin’s filenamesearch, you now might be using rg/rga search. In distributions like Fedora where only ~/Documents, ~/Music, ~/Pictures and ~/Videos are indexed by default, you’ll use Baloo when you are in those directories and rg/rga search or filenamesearch when not.
Looks like rg will be faster, maybe quite a bit faster, than the current filenamesearch when dealing with content searches. Yes, despite the name filenamesearch can do content searches. Filename searches themselves won’t change (at least without further work)
It looks like rg/rga is only going to be used on a subset of mounted filesystems, it skips those accessed via kio-fuse. Samba and ssh are mentioned. The old NTFS drivers did but the new Paragon drivers do not. There’s NFS and there are “exotic” filesystem combinations (like vaults?) that might depend on fuse. Making such a list is probably going to take time.
The ~/.local/share/kio_filenamesearch/ is there for an override, you won’t get a script copied there but if you set up one, it will be used in preference to the system script, /usr/share/kio_filenamesearch/kio-filenamesearch-grep
Rg/rga is probably not going to be faster than Baloo as Baloo has done the indexing “in advance”. The ideal is that you can choose freely between the tools.
If I’ve got anything wrong here…
I’m not getting the replies in the right place here… sorry. Maybe this is better:
Yes, people who want to try ra/rga but still rely on Baloo…
Do you have a reference?
It should be “something simple”, people are going to move to a folder and start typing search terms. How do they know what search tool they are using?
Switching the search providers ought to be in System Settings.
IIUC, it will be used on all filesystems already mounted. What it won’t do is to mount “remote” kio protocols (e.g. smb: or fish:) on-demand via kio-fuse (in order to run rg) when you search in Dolphin.
@jinliu
Thanks for implementing this. Is there any way to promote this to distros, so they will include ripgreap to the list of “recommended” additional packages for kio-extras? Unfortunately, sometimes distro maintainers don’t notice newer KDE developments (e.g. kio-fuse, krdp) until users create related issues.
I think the idea is right (to allow people to select what they want) but the place was wrong.
In System Setting > File Search it could look like:
Baloo File Indexing:
[ ] Enabled
Data to index:
( ) File names and contents
( ) File names only
[ ] Hidden files and folders
Search in Dolphin:
[ ] Should use Baloo index
And then:
( ) Should use rga
( ) Should use rg
( ) Should use customised script
( ) Should use internal filesearch
Where the ( ) are radio buttons and are checkboxes. That gives the whole range of options…
Having the option for customised script saves you from your worry about running a script “just dropped” into ~/.local/share/kio_filenamesearch/