GNOME Bugzilla – Bug 153563
add possibility to use either locate or find from GUI
Last modified: 2009-08-15 18:40:50 UTC
bug 140258 tells that locate is disabled for searching the user's home dir because the results often are outdated. Well, may files in my home dir don't change and I'd like to use the search tool to quickly get the full path to them. Since find takes too long I use command line "locate" instead. Note that the following proposal should only be used for simple seach (e.g. file-name only) The proposal is * use locate first and display the results found with locate. -> the Search/Stop button should change to "update" or similar * After the locate command has finished, immediately run the find command you'd normally run. * When the user chooses "update", replace the results of locate by those of the find command. (if the find command is not finished yet, convert button to "stop") The time spent/wasted for the locate command should be negligible since this proposal should only be used for file-name only searches (no other tools than locate involved) version is 2.8.0 but that is not available, so I picked 2.6.x)
This enhancement is a hack that introduces too much complexity. If you want to use the locate command when searching your home folder then set the /apps/gnome-search-tool/force_quick_search gconf key using the GConf editor. This will force the use of the locate command for all simple filename searches.
Dennis - Perhaps we should add a discussion of "force_quick_search" to the documentation?
Hi John, I am still contemplating if the logic used to determine when we should use locate or find should be changed. Yes, documenting the 'force_quick_search' is a good idea. We already document the 'disable_quick_search' key.
I change the summary back to reflect my original report. I already filed a documentation bug #153562 along with this one. The gconf keys won't help my situation. I want to be able to use both without having to modify a gconf setting everytime. -> First try locate, if that doesn't get results, run again using find. I want results quickly (->locate), but sometimes the locatedb is outdated (-> have to use find instead). Having a gconf switch doesn't help (takes too much time to switch between the modes) I make a revised proposal: * Keep the gconf keys of default directories for which locate shouldn't be used (removable media, and the like) * keep the disable_quick_search key (the force_quick_search key doesn't seem necessary to me if the proposal gets accepted since quick search would be default - it would only act as a hack to override the directory-gconf key - maybe it could force use of locate when searching for contents as well) * if the extended options are collapsed (file-name only search) use locate (unless otherwise specified by the gconf-keys) * if the options are expanded (no matter whether the options are used or not) use find (there already is a difference between the two "modes", see bug #15569) While I'd still like the first suggestion better (for file-name only search use locate and change button label to "update", "refresh" or similar. If the button is pressed again, run search using find). I don't agree that this would be a hack (why should it be a hack?) and I don't agree that it would add complexity (at least not to the user) but since I cannot code it myself... If you mean the point that find should run after locate has finished without the user hitting "update", well than forget about it. Only run find if requested by the user. But in any case the behaviour has to be changed, otherwise it is way too inferior compared to commandline.
Ahh, should have had a look at the gconf keys before writing that comment. * don't keep the directory list static, but editable, so create a key "disable_quick_search_dirs" or whatever you want to name it (holding a list of directories seperated by colon) with a default value of /proc:/dev:/mnt.... So the following gconf keys should be present: [1] disable_quick_search (-> disable locate completely) [2] disable_quick_search_dirs (-> don't use locate for dirs specified) [3] force_quick_serach (-> always use locate, overrides [2], as if [2] was empty)
Comment #5 is reasonable. That's basically what I was proposing. Regarding comment #4... > I don't agree that this would be a hack (why should it be a hack?) I called it a hack because the problem here is we don't have a good indexing system for GNOME and no combination of using locate and find will solve this. What we really need is something like medusa (or beagle?) that will maintain an updated index of the filesystem. > (there already is a difference between the two "modes", see bug #15569) Looks like you missed a digit on that bug number?
*** Bug 153569 has been marked as a duplicate of this bug. ***
This enhancement will have to wait until after we branch for GNOME 2.10.
Yes I missed a digit, but bug #153569 is not a duplicate of this one. comment #5 is only part of a solution. Such an editable list of directories and the other gconf-keys are a base configuration, but for real life this still doesn't work. Example: I search a file in my homedir -> find is forced -> Search takes *two minutes* to display anything. for a simple filename search! locate returns instantly. I know I have that file somewhere but don't remember the full path, so I have search for it. But I definnitely don't want to waste two minutes waiting for a result. With the current restrictions, I have to use locate on the commandline. If I had home mounted from a different machine, the find command would take even longer and cause unnecessary traffic. But again it may be that the file is new so the locatedb won't have it indexed. In this case I have to use find and and wait. So when I remove /home from the "force-find-dirs" I would get my result quickly, but in order to use find for the new file. I'd have to edit a gconf-key, run the search again and then reset the gconf-key. Somehow gsearchtool has to offer both methods from the gui. If not it is pretty useless (if you need commandline anyway, why launch gsearchtool first?) And again I disagree. You write "no combination of using locate and find will solve this". It is not about combining these two, but to use one *or* the other. Sure, you can say that medusa or beagle will solve this - but why wait when you can improve the current situation a lot without much effort? What about sites that don't install an additional indexing system?
Christian, it doesn't help your argument by claiming that the search tool is "useless". There has been no flood of bug reports submitted to bugzilla to substantiate that claim. Also, you can't make the claim, "you can improve the current situation a lot without much effort". If you do not understand the source code then you do not know how much effort this change will require. To make things clear, I do not want to expose the complexities of locate and find in the UI. If usability experts disagree please add comments and/or suggestions to this bug report. I am open to reasonable suggestions. Thanks.
For the record, I agree with Dennis that exposing the complexities of "locate" and "find" in the UI is a bad idea. I also agree with Dennis's comment that a Medusa-like system is the preferred long-term solution here. (And, as an aside, I think we should all *really* appreciate Dennis's efforts to keep gsearchtool maintained until that better solution arrives.)
Focusing on a single word, tearing that out of context and ignoring the rest of the arguments is pretty lame. (BTW: No bug reports can mean nobody's using it as well.) > Also, you can't make the claim, "you can improve the current situation a lot > without much effort". If you do not understand the source code then you do not > know how much effort this change will require. Hello? You already have the desired behaviour! compare bug #153569 The only thing to do is not to check whether one of the options is actually used (which is/was not the case, it was enough when the option was visible) but to check whether the list of options is expanded. How much effort would that be? How useful is a long-term solution that will be available in a couple of years? I need a solution now, not when the perfect one is ready. It is not my intention to be disrespective and I don't want to diminish the work that has been put and is put into gsearchtool. I filed this bug because I want it to be improved. No more - no less. If you don't want to add the ability to be able to use both ways from within the GUI- then be so honest and close this one as wontfix, but don't convert this issue to a completely different meaning. I'm sure that even when if the options "() quick search" and "() thorough seach" were added to the GUI (again: I do not request additional GUI-elements!) the user would not be swamped with complexity.
> Hello? You already have the desired behaviour! compare bug #153569 The only > thing to do is not to check whether one of the options is actually used (which > is/was not the case, it was enough when the option was visible) but to check > whether the list of options is expanded. How much effort would that be? What are you saying here? I don't understand this comment.
I have been thinking about this a little. I don't know if this is a good idea or not, but what if after performing a search that uses the locate command we add a popup menu item to the search result's list that allows the user to perform the same search again using the find command? This would keep the feature hidden from the average user, but available for more advanced users. Any thoughts?
You mean a right-click menu ? This would be hard to discover, but why not. Why can't we just first show the results from the locate command, and then run the find command, updating the entries that need updating in the list ? (I'm sure I don't see all the sides of the question here, I'm just trying to understand ;-)
Right, the popup menu is the same as the right-click menu. My concern with running the locate command and then running the find command is that from a user's perspective the entire search would take longer. In some cases, the find command will take much much longer to perform a simple filename search.
Created attachment 32977 [details] [review] Patch: work-in-progress Today is a rainy day, so I played around with the locate and find logic. (This is a work-in-progress patch that may end up going no where.) After applying the patch, when gnome-search-tool performs a simple filename search that uses the locate command, it will perform a second search using the find command and add files to the search results list that are not found by the locate command. Anyone want to try it out and give feedback?
Created attachment 32980 [details] [review] Patch: Take two.
Created attachment 33058 [details] [review] Proposed patch. If I don't receive any complains this patch might just make it into cvs. 2004-10-25 Dennis Cranston <dennis_cranston at yahoo com> Fix bug #153563: Add internal logic to perform a two scan search for simple filename searches. A quick search will consist of an indexed search that uses the locate command followed by a thorough search that uses the find command. The quick search and second scan logic can be disabled with gconf keys. Advanced users can fine tune the quick search and second scan logic by adjusting the new excluded path gconf keys. By default, a quick search is not performed for the paths: /mnt/*, /media/*, /dev/*, /tmp/*, /proc/*, and /var/*. By default, a second scan is not performed for the path: /. * gsearchtool.[ch]: Add first pass, disable second pass, and a file hash to the search_command structure; build_search_command(), handle_search_command_stdout_io(): add first pass logic handling; add_file_to_search_results(): do not add duplicate files in the search results. * gsearchtool-support.[ch]: Add the function is_quick_search_excluded_path(), is_second_scan_excluded_path() and gsearchtool_gconf_get_list(). * gsearchtool-callbacks.c: Pass a boolean for the first pass to build_search_command(). * gnome-search-tool.schemas: Deprecate the force_quick_search key. Add three new keys: quick_search_second_scan_exclude_path, quick_search_exclude_path and disable_quick_search_second_scan.
The patch works for me. Congrats for making this work without adding any UI complexity !
Vincent, Thanks for the feedback. I am checking these changes into cvs. John, I added a new section no. 4 to the documentation. If you have time could you please proof read section 4 and fix the verbiage, grammar, etc? Chris, I am marking this bug resolved. Regarding your no bug reports comment in comment #12, your bug report was the 171st bug filed against gsearchtool. There are no open bugs against gsearchtool because each of the bugs is obsolete, fixed, resolved, or closed. Here is the complete list: http://bugzilla.gnome.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&product=gnome-utils&component=gsearchtool&long_desc_type=allwordssubstr&long_desc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=anywords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= 2004-10-26 Dennis Cranston <dennis_cranston at yahoo com> Fix bug #153563: Add internal logic to perform a two scan search for simple filename searches. A quick search will consist of an indexed search that uses the locate command followed by a thorough search that uses the find command. The quick search and second scan logic can be disabled with gconf keys. Advanced users can fine tune the quick search and second scan logic by adjusting the new excluded path gconf keys. By default, a quick search is not performed for the paths: /mnt/*, /media/*, /dev/*, /tmp/*, /proc/*, and /var/*. By default, a second scan is not performed for the path: /. * gsearchtool.[ch]: Add first pass, disable second pass, and a file hash to the search_command structure; build_search_command(), handle_search_command_stdout_io(): add first pass logic handling; add_file_to_search_results(): do not add duplicate files in the search results. * gsearchtool-support.[ch]: Add the function is_quick_search_excluded_path(), is_second_scan_excluded_path() and gsearchtool_gconf_get_list(). * gsearchtool-callbacks.c: Pass a boolean for the first pass to build_search_command(). * gnome-search-tool.schemas: Deprecate the force_quick_search key. Add three new keys: quick_search_second_scan_exclude_path, quick_search_exclude_path and disable_quick_search_second_scan. * help/C/gnome-search-tool.xml: Remove section 3.7. Add a new section 4. Document the various gconf keys in the new section. * help/C/figures/gnome-search-tool_window.png: Update for newest gtk+ 2.5 file chooser button widget changes.
I failed to apply the patch to my version, so could anyone plese tell me whether the list of results changes automatically, e.g. without the user doing anything? I personally wouldn't like it if I do a search, open one of the files of the results - do something - go back to the list and suddenly a bunch of other files are listed and I cannot tell what happened. "Regarding your no bug reports comment in comment #12 [...]" I'm tired of having to cope with people that keep picking on other people because of single words or statements that are teared out of context and misinterpreted by bad will. out of context because: * the remark was a side note * the remark was about reports describing *this* problem, not problems with gserachtool in general. * it was intended to show that the number of bugreports is not representative of the number of people using a software, and not representative of the wishes the people have regarding the sowtware. I don't care anymore because you don't try to listen/understand what I am trying to say. Furthermore you seem to have a substantially different point of view regarding "the complexity of the UI". If the view is replaced without interaction, this is what I would call bad (because it is not easy to understand what happend) UI-design. If this is the case, I don't think that I will not use gserachtool more often in future. (I know you don't care - neither do millions of others)
The list of results is updated automatically : if the find command finds new results, these results are appended to the list, they do not replace it. But as the search icon is still animated, the user should understand that the search is still ongoing, and that it is possible that new results will be appended to the list. So there should be no confusion here.
I agree with Vincent that the confusion Christian suggests is unlikely to happen. I disagree strongly with Christian's assertion that, "I know you don't care." That's just plain idiotic. Dennis has spent the time to try to come up with a thoughtful solution, despite the fact that Christian's frankly been rude about it all. Christian - Saying you didn't go to the trouble to build it yourself, but that you're sure it must suck, as you just said above, is pretty lame. Dennis cared enough to try to fix this. You don't even care enough to build it.
Again: please READ what I *wrote* (and not what you think I may have had in mind)! Again you tear my statemenst out of context and complain unnecessarily. The "I know you don't care" was meant to *diminish* the statement immediately before ("if [...] I won't use it more often") I wrote "I failed to apply the patch to my version" - I tried to compile myself. I have compiled the whole gnome desktop myself. It is not the case that I am unwilling to compile. And you write "you're sure it mus suck" but again these were not my words. I coupled this to a if-statement. The if-statement is not true thus the rest doesn't apply. Conditions. You read my comments as being rude because you expect it to be rude (be assured that they aren't meant that way). Read my comments again without being biased (And without having your feelings influenced by comments from others) and judge again. If you still think I was rude I apologize. But if you tear my words out of context and draw wrong conclusions, this is your problem. I can live with that. FYI: Thanks Vincent for answering my question. Having the results appended is a solution I can live with.
I read what you wrote. It was pretty clear. Dennis worked hard trying to fix your bug. That proves he cares. You wrote, "I know you don't care." That's rude.
That last statement shows that you don't read what I write, but what you want to read. Again: Your problem.
John, Thanks for taking the time to proof read my updates to the user documentation. Vincent, Thanks again for testing the patch. Regarding Christian remarks in comment #25, they are mute. He has not tried the patch and does not understand how it works. I do not have the time to address his other pointless rants. I am closing this bug report.