Okay, but the KDE developer above said that ripgrep-all will work when baloo is not indexing files? I thought it meant that they conflict in some way, but now I feel like they are supposed to complement each other?
On another note, can we confidently say that I will not have to purge and recreate my index file all the time because of its growing size? Baloo will remove deleted files, but just not immediately, since they might be on a removable drive or something? Shouldn’t there be a configuration to separate the treatment of mounted directories from the regular home directory?
Another problem I have with baloo is that, I have a folder home directory called “Books” that I indexed completely, nothing failed. So, when I search something on my home directory, results come up from that folder. When I move one level up (where i see the different users, in the /home directory), none of those files come up. This create a bad habit for me, where I recheck everything with me, since it looks so unreliable.
The basic logic dictates that if I get x results, and I go back 1 folder, I should still be getting at least the same number of results, not with Baloo.
This really is NOT a problem - as indexed files instantly appear in krunner - so if you save, for example, a script… it gets indexed and krunner will pull it up.
Baloo also, once it has done it’s initial scan, doesn’t interfere and just runs low background priority (mostly it’s idle when you’re using the machine).
File searching is a much more intensive process, so it’s best to only use that for files not in your regular indexed folders.
That I understand, I just read in a few places that in order to get rid of deleted files, I have to purge and recreate the index file from time to time? I find that process extremely exhausting, because baloo crashes very frequently (it says recursivecounter = 2) and I cannot report it due to it having “low informational value”.
I am fine with it taking 5-10 GiB of space but it should remove non-relevant data. The question is, does it?
https://wiki.archlinux.org/title/Baloo Once you added additional folders to the blacklist or disabled Baloo entirely, a process named baloo_file_cleaner removes all unneeded index files automatically. These are stored under ~/.local/share/baloo/.
I don’t understand, if it removes them, why does it store them in in the “baloo” folder?
They complement each other but we do not have a toggle in the user interface yet to allow switching between the two. So for now the ripgrep-all search is only used when Baloo is currently not available for a folder.
I see. I understand the value of baloo when it comes too assigning tags, etc. So, I might still want to index my folders. However, I noticed that ripgrep-all searches like Fsearch and Nemo, it finds everything; Indexed, non-indexed, system, hidden, etc. + their content. So, I am quite satisfied with it when it comes to searching. if I turn off Baloo (despite having indexed my home folder, for example), can I still use ripgrep, or will I have to delete the index file every time I wanna use ripgrep?
I just tested that ripgrep-all works while Baloo is enabled (active or idle, not sure, though). I wish they fixed the bugs of Baloo instead, even ripgrep-all wouldn’t be necessary then.
Dream scenario would be Dolphin being able to aggregate search results from different backends that the user can toggle individually, rather than the current “fallback” strategy.
Honestly, has anyone here used Nemo? Its search works flawlessly. You don’t need indexing or anything. What would it take to make Dolphin search like Nemo? Both are open-source projects, aren’t they?
I don’t have a comment on Dolphin or Baloo, but I want to address the whole “just copy $OTHER_PROJECT, it works fine!” line of thought.
You can’t rip out a feature from Nemo and implement it in Dolphin; the two have different tech stacks. The fact that both are open-source is irrelevant; their technologies simply aren’t plug-and-play.
It would be like asking to take the drivetrain out of a Toyota Prius and put it in a Ford F150. Could an engineering team derive inspiration from the former when developing a new version of the latter? Sure. But it would not really save any work or time, and it would still be a giant project that amounts to redoing much of the product from scratch.
My bad, I didn’t mean simply copying one over to the other, of course.
What I meant was that Nemo has a very intuitive search function. It simply looks for the given string, either in the filename or in its content. Nothing more, nothing less. Dolphin, on the other hand, has very weird tendencies that make no sense.
For example, I don’t understand why my results disappear because I move one level up, to my parent folder, that is, or why it finds some words in a .docx file, but misses others. Nemo doesn’t have any of these issues.
I don’t think this is a totally good analogy though. In software we have abstraction, IPC standards and APIs.
Then, in practice, in the Linux desktop world it is very hard to design things with interoperability in mind and even when specifications exist (Freedesktop) their adoption is never frictionless.
I am just a little confused about this. Something like searching is a very very straightforward process for me. You put in a keyword, maybe add some additional parameters, such as case sensitive, search in substrings, etc. and maybe assign a search location. Dolphin/Baloo cannot seem to get very basics right, to the point that I have to verify things that I earlier considered to be no-brainers.
As mentioned earlier, I don’t think one needs to reinvent the wheel here. There are a few tools that work very intuitively to achieve this, ripgrep, Recoll, etc. One of them needs to be integrated with an option to index things. I am looking forward to ripgreg for this very reason. It was like faster Nemo to me.
