When searching for files in folders within dolphin it is very hit or miss for a match when the text clearly contains the characters being searched for. As you can see in the attached screen capture that it doesn’t display the proper results when searching within a folder or folders.
I’ve created an issue about this here a while back, but so far it hasn’t been addressed. Hopefully it can be corrected at some point before plasma 6.
System Specs:
Operating System: KDE neon 5.27
KDE Plasma Version: 5.27.7
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Kernel Version: 6.2.0-26-generic (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 5600G with Radeon Graphics
Memory: 16.0 GiB of RAM
Graphics Processor: AMD Radeon RX 5500
So, supposedly the problem is that in the search directory there are 5 files with the text “frame” somewhere in their filename.
When searching for “frame”, only 1 is found
When searching for “fram”, only 3 are shown
When searching for “f” none are hown.
I believe the search is powered by Baloo, so if the issue is in Baloo and can probably be reproduced on the command line by running baloosearch -d ~/SearchTest "frame".
So this is how it looks on my system, after recreating the SearchTest folder with its 5 files:
$ ls searchtest/
dataframetest.txt data_frame.txt dataframe.txt framedata.txt _frame.txt
$ baloosearch -d searchtest/ "frame"
Using canonical path '/home/odeda/Documents/test/searchtest' for 'searchtest'
/home/odeda/Documents/test/searchtest/_frame.txt
/home/odeda/Documents/test/searchtest/framedata.txt
/home/odeda/Documents/test/searchtest/data_frame.txt
Elapsed: 1.18328 msecs
$ baloosearch -d searchtest/ "fr"
Using canonical path '/home/odeda/Documents/test/searchtest' for 'searchtest'
kf.baloo.engine: PostingDB::iter "fr" MDB_NOTFOUND: No matching key/data pair found
/home/odeda/Documents/test/searchtest/_frame.txt
/home/odeda/Documents/test/searchtest/framedata.txt
/home/odeda/Documents/test/searchtest/data_frame.txt
Elapsed: 1.11661 msecs
Yes, this is obviously an issue - of user expectations if not of anything else.
I think the main problem is that people think “substring search” while Baloo is doing some sort of “prefix word search”, so it finds “frame” in various files that have that word in a “clearly distinct manner” in their name (for a computer algorithm definition of “clearly distinct”), and it will also find “fram”, “fra” and “fr” - but not “rame” or “ame”, and - maybe surprisingly - not “f”, because that is not enough letters. When you search for “f”, Baloo will find “f.txt” but not “fa.txt” or “fail.txt”, but it will find those last two if you just search for “fa”.
In the example we see Baloo skipping files with the text “dataframe” in them, because Baloo doesn’t understand that “frame” is a distinct word in the combination “dataframe” - which is understandable because Baloo does not have an English vocabulary. It will find all of those files if you search for “data”.
I think the bug linked above and the bugs referred from it are a good place to continue tracking the discussion, and I also think that the current behavior is not a “unintended behavior” (what we often mean when we say “bug”), and not “wrong” - in the sense that it is useful, especially for people who aren’t computer savvy, and solves many problems with locating files with “human names”.
