(*** This bug was imported into bugs.kde.org ***) Package: kfind Version: KDE 3.0.6 Severity: wishlist Installed from: compiled sources Compiler: gcc version 2.95.4 20011002 (Debian prerelease) OS: Linux (i686) release 2.4.18 OS/Compiler notes: Hi It would be great if there is an extra from were you add forldert that should not be searched. E.g. search for a file in / but dont search in /var/log;/usr/man;/etc That will speedup the search and you don't have to search every folder for it once. thanks have fun Felix (Submitted via bugs.kde.org) (Called from KBugReport dialog. Fields Application manually changed)
If several users wish this feature, why not ? But I'm afraid KFind's interface becomes overloaded by options...
I think we have to do something about the kfind user interface. Already the fact that it is spread over three tabs is not good. On Mac OS X you can select a list of directories to search. At first there are only a few options, and you can click something like "add more options". Maybe we should also add an option to interpret the content of the "Named" file lineedit either as regexp, or as a shell pattern as it is now, or even simpler "the file name has to include the text entered in the lineedit", i.e. simply entering "kde" would mean the same as "*kde*" does now. Also the ability to save a set of search parameters would be nice. Alex
*** Bug 118912 has been marked as a duplicate of this bug. ***
I think a good solution would be using Checkboxes instead of the "Choose folder" menu. I made a KDE-Look suggestion and it seems to be popular there. http://kde-look.org/content/show.php/Checkboxes+on+Kfind?content=61322
Is this still relevant?
See-Also: https://bugs.kde.org/show_bug.cgi?id=129992
One of the great things about Kfind is that it has an intelligent interface with lots of options. The tabs work well. They make sense. There's room for more options under each tab. There's room too for more tabs. Users are not typically stupid. The last thing you want to do is adopt a Fischer-Price Gnome app interface that you can only operate with your thumbs, your fists and your forehead. You want to be going in the other direction. Give users more and more intelligent options. The problem with a lot of apps is they assume users are stupid, so give them nothing but numpty options. Users are intelligent. They just don't know how to use sed and awk and all those other things spawned in hell, and that knowledge of which linux administrators and systems programmers think makes them special. Users don't have these skills because they are not systems programmers. Their expertise is in other things. But they would very much like to do the obvious intelligent things with their computer, like find certain files in a gui to the exclusion of certain others, and not be forced to read that horrid, horrid 'find' manpage, and then to get the results in a gui so they can do gui things, like drag the results into a Kate text editor window, or just scan the list and sort, and so on. You know - real world, human things. KDE inability to exclude files is a glaring fault in an otherwise brilliantly simple search tool. So many other tools are simply simple.
Wow! A 20+ years old feature request, completely reasonable, absolutely needed, and completely ignored by devs. KDE at its finest!
(In reply to Dennis Schridde from comment #5) > Is this still relevant? Yes it is.
I had an S3 remote mounted with rclone in ~/mnt/s3, and KFile just crawled the complete entirety of to find the one text file in which I emergency-saved an important bit of information half a year ago. And no, I did not save that file on S3. That's the kind of harm that happens when you can't exclude folders from search.
> The last thing you want to do is adopt a Fischer-Price Gnome app interface > that you can only operate with your thumbs, your fists and your forehead. These days I only revisit lost cause bug reports for random pearls of UX humour like this.