Version: (using KDE KDE 3.2.1) Installed from: Compiled From Sources OS: Linux Many users think KFind is broken because it fails to find files named File1.txt File2.txt when they enter "File" as a search string. I think that KFind should interpret "Name" like "*Name*" by default, unless the user checks an option called "Exact Match" or something. Ideally, KFind should also find more fuzzy matches, such that it will still find a file when the user does not spell the name correctly.
Although I'd certainly turn this feature off, I tend to agree. First time users expect to be able to enter part of a filename and not have to use wildcards to search. However I don't think the fuzzy search is a good idea. It would just return too much irrelevant garbage if you forget to turn it off. I think it's reasonable to expect people to know how to spell what they're looking for.
> It would just return too much irrelevant garbage If you use an algorithm that will assign a smart score to each result, you will always find the mose similar hits on top. Note that Google works exactly the same. You may get 100.000 hits, but most of the time, you will find your target in the top ten. > I think it's reasonable to expect people to know how to spell what they're looking for What I actually meant was that people might forget the exact name of the file they are searching for. Technically, this is the same as allowing the user to make spelling errors in their search queries.
I planned to add a combobox in front of the filename: Filename contains: Filename matches wildcards: Filename matches regexp: Not sure this can be done in the 5.3.x series (string freeze)
*** Bug 111779 has been marked as a duplicate of this bug. ***
> I planned to add a combobox in front of the filename: I'm a bit worried this makes it find only more confusing. I'd rather like to search for files like I search for pages in Goole, songs in Junk, or files in Windows. MHO, Find should use "*word*" internally by default. Only Advanced users like to do stuff like wildcard matching, exact matching, or start-with matching. But fortunately, they're smart enough to figure out how to use regular expressions for that (^word$). This is not something you need to have prominently visible for all users.
I agree. Power users will probably even prefer commandline, while unexperienced users will mostly use KFind and are used to how Google or the Windows XP file search work.
Currently the label in front of the lineedit says "Named: " [ thefilename ] Then it would look like: Name "contains ^": [ thefilename ] I.e. the "contains" will be the default, wildcard and regexp will be the two other options in the combobox I don't think this would confuse users more. Alex
> Currently the label in front of the lineedit says > "Named: " [ thefilename ] > Then it would look like: > Name "contains ^": [ thefilename ] > > I.e. the "contains" will be the default, wildcard and regexp > will be the two other options in the combobox I got that part, and it's exactly what I'm worried about. It's the same reason I always use the listbox search bar in KMail and *never* use the Find dialog there. It's not I lack any "capacity" to comprehend the dialog, but I actually have to take time to carefully read the labels, understand what it means and choose the correct options to get what I want. This is something you only want to do when you're really looking for something specific, something that's worth spending time for. You don't want to read the dialogs before you can search.
*** Bug 111696 has been marked as a duplicate of this bug. ***
Agreed with this addition. And do keep it as simple as possible. If you're going to add options for exact and regex matches, then put them under and "Advanced" tab or something.
The majority of computer users don't know what wildcards are, and they shouldn't have to. The default option should not require wildcards. Even though I've used wildcards many times, I thought KFind was broken. Why? Because there is nothing to inform users that KFind requires wildcards! Requiring wildcards without letting the user know is extremely bad design. Even advanced users can become confused by this. I would prefer a drop-down list labeled "Search method" with the options "substring", "exact match", "wildcards", and "regular expression". Whatever kind of interface is chosen, substring matching should be the default. If it's not, KFind should at least tell the user what kind of input is required.
+1 vote for Alexander idea -- and the words are good too "contains" is better than "substring search".
*** Bug 144263 has been marked as a duplicate of this bug. ***
I have verified this bug as present in the latest KFind (v24.08.4) I think it is wrong to assume that the end user knows what wildcards are and that they are essential to use KFind. The status quo is definitely confusing for novice users. Personally I would like to retain the current functionality but somehow communicate the functionality better to the end user. Here's what I propose: 1) By default (on launch of KFind) use a search example that heavily implies the use of wildcards such as: *.txt My rationale is that our intended user audience should at least be aware of .txt files so they should be able to put 2+2 together and figure what the * stands for. 2) On mouse hover over the text field a helpful short explanation of what wildcards are + alternative search examples could also be included. 3) If not on mouse hover then perhaps it could be an initial greyed out explanatory text (inside the text field) before the user types anything. Any of the above will be a nice improvement over what we currently have.