| Summary: | KFind: add a maxdepth option | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | tdebase | Assignee: | Calvin Morrison <mutantturkey> |
| Status: | NEW --- | ||
| Severity: | enhancement | CC: | bugwatch, darrella, michele.calgaro, mutantturkey |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | All | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 2969 | ||
|
Description
Darrell
2011-11-27 11:09:35 CST
Hello I've looked into this and my mind is pretty much boggled. I would have assumed that KFind would be basically a frontend to the standard find command available on all GNU and Unix systems; In fact they use a KIO Job to search for files, then examine the files on by one, and filters them out by seeing if they match the user submitted arguments. (size, date, type, etc.) The problem is that the KIO Job does not support options for different depths. It either returns all subdirectories or no subdirectories. So using the KIO Job is out of the question. That leaves the option to look at the filepath of each file and see if they have a certain number of forward slashs. (maxdepth=1 is current directory, maxdepth 2 is one folder, so search for one / or 2 / respectively) The third and most intensive solution (but will probably bring major performance improvements (not sure about that but my guess is yes) and will support all of these, if not more options (find has a very extensive set of options and tests), is to rewrite the backend using find. Using a KProcess of find with the correct arguments, then feeding the stdout into a list seems relatively simple Thoughts? Am I reading into this to much? Calvin Morrison Sounds complicated. :) I thought I once read that KFind used a layered approach. If the parameters were simple, and an slocate database existed, KFind used that to list the file. Is that still true? Just curious --- an slocate wrapper does nothing to support maxdepths. This is an enhancement request I'd like to see implemented. I'll try to learn whether other GUI find tools support maxdepth, If so then we could use the code. When we find a solution to this request, let's add KFileReplace (tdewebdev) with the same maxdepth option. Great little tool. BTW, possibly KFileReplace uses different algorithms that might improve KFind. KFileReplace is quite fast, whereas KFind often seems quite slow. Maybe we need to fix KFind to use built-in tools. KFind uses slocate but I had always assumed the find command was used too. Changing status back to NEW for too long inactivity Note: Michele added a maxdepth option in tdefilereplace. Refer to bug 1238. I don't know whether the same methods can be used for kfind. Will need to check the code, but the logic is probably similar. |