GNOME Bugzilla – Bug 78865
Bad result presentation
Last modified: 2009-08-15 18:40:50 UTC
When searching for files with a simple pattern, the search will show all files and subdirectories inside a directory if the directory itself matches the pattern. This gives you far too many results and makes it nearly impossible to actually sort out the proper results. The correct way will probably be to surpress all results that are found ONLY due to the fact that its path contains the pattern. If someone desperately wants to show all results, then I suggest a collapsed tree. The search result is after all shown in the list view widget.
Probably won't happen. Locate doesn't provide an easy way to handle this. Perhaps there is an advanced option to search for directories? I haven't checked yet and don't have access to the app right now.
Created attachment 7741 [details] The man page for locate on RedHat 7.2.
Could you be more specific about what it was in that man page that's relevant?
I've posted a patch.. to desktop-devel-list that makes all files and subdirectories under the actual match appear in a collapsed tree. For instance, the regular result of locate and therefor gsearchtool is: Searchword: cool Results: /home/whatever/cool/ /home/whatever/cool/README /home/whatever/cool/floff /home/whatever/cool/src /home/whatever/cool/src/main.c ......... This obviously creates WAY to many results. My patch makes it look like this: + /home/whatever/cool And you can click on the expand sign to get all the rather uninteresting sub-results. The sub-results makes the dialog get so many results that it is impossible to actually find the correct one. Righy now however, I'm way too drunk to explain it properly. Good night :)
Gaute: could you attach the patch to this bug?
Created attachment 7815 [details] [review] The actual patch
Created attachment 7817 [details] [review] The last patch was wrong! :P
As specified in an email this patch should be redone without indent having been applied.
I would like to add a comment on this patch. I did apply it to my local version of gnome-search-tool, and I have one problem. When I perform a simple search all the "correct" matches are not contained at the root level. For example, I have these two folders /home/dcransto/mozilla and /home/dcransto/mozilla/mozilla. When I perform a search for "mozilla" only the first folder is shown at the root level in the results. The second match is hidden under the first mozilla folder's node. So, the user will not be aware of the second match. Thanks, Dennis
Ok.. I'll redo the patch with no usage of indent and try to fix the second problem (matches in the tree below the original match). Does anyone have any idea on how this should look? I think using my "tree-view" will probably be overly complex on second thought. The locale-output will probably have to be parsed and sorted. I'm in favour of not showing results that does not match more than just their parent-dir. Tbis means that searching for "cool" will yield: /home/lindkvis/cool /home/lindkvis/cool/smart/cool And not: /home/lindkvis/cool/README (.. 50 other files ...) /home/lindkvis/smart /home/lindkvis/cool/smart/cool /home/lindkvis/cool/smart/ChangeLog (.. 40 other files ...)
Created attachment 7973 [details] [review] Ny og oppdatert patch.. inkluderer også oppdatering for Nautilus OAFIID som postet på desktop-devel-list
Uhhm.. somehow I posted the description of my last patch in Norwegian. "Ny og oppdatert patch.. inkluderer også oppdatering for Nautilus OAFIID som postet på desktop-devel-list" Means: "New and updated patch.. also includes update for Nautilus OAFIID like posted on desktop-devel-list". Sorry about that :)
Gaute- A Nautilus OAFIID patch has already been checked in to CVS. I will try your patch this weekend. Thanks! -- Dennis
Created attachment 7983 [details] [review] Modified patch for CVS.
I have modified Gaute's patch file to remove the redundant Nautilus OAFIID changes. I recommend applying the patch to CVS. Gaute has done some excellent work. His changes will make the simple tab results much more useful. Thank you Gaute!
Hum, I haven't committed this yet because when I patched my source it didn't seem to make a difference. Seems like a useful thing to have for 2.0 with very little code involved.
Glynn - If you are running this patch on a solaris box, you will not see any changes in the results. This change is for platforms (such as linux) which have the locate command installed. Hope this helps clear things up for you.
Nah, I'm running it on Debian PPC on my iBook. Will investigate tommorrow.
I use "basename" as a criteria for matching the search-pattern. I also use utf8-functions before pattern matching.. I only have an x86- box, but I have trouble seeing what I did that shouldn't be portable. If you'd investigate this further, that would be great. Since I only used glib-functions, they should all be portable. At least none of the functions explicitely stated that they weren't portable.
Oh, me bad. Sorry, I misread the bug report that said you were going to do a treeview with +- |- Have applied the patch in CVS as it seems like a good idea. Thanks for the patch Gaute...and for the modifications Dennis :)