Community
Participate
Working Groups
I believe that more people would find Java Search more useful if it defaulted to the most general search possible: where it searched for the string in all occurrences of all types and methods and package names and constructors and fields in the entire workspace. Why? I just got done doing a user study, where I watched seven developers closely doing four Java coding tasks with Eclipse-based tools, then interviewed them. I found that people used File Search much more often than Java Search, even when a Java Search would have been more appropriate. When I asked them why, they said that there were so many buttons on the Java Search that it was easy to get it wrong, and hence to miss real results. With the File Search, they got a bunch of false positives, but that wasn't nearly as important to them as avoiding false negatives. I thus recommend that the Java Search be changed to default to the widest scope, with checkboxes instead of radio buttons for the "Search for" options (type/method/package/constructor/field). For people who want backwards compatibility, it could (*sigh*) be yet another prefs option. I feel pretty strongly (based on my user study) that the default should be to a wide scope. Note: I'm not sure if JRE libraries should be part of this "widest scope" or not. So maybe it's not *quite* "widest" scope, but it's pretty close.
The Java search page always remembers the last used scope. So unless you changed it from 'Workspace' (which is the widest scope), you will always use 'Workspace'. Is that what you mean? This is the same in file search.
Sorry, I'm using "scope" in the broad English-language sense, not the narrow CS meaning of "scope". Yes, it does stay at Workspace for the (CS) scope. But the search is also restricted by default to one of the types (in the English sense, not the CS sense, small T) of Java elements: Types, methods, fields, etc. It is also restricted to one of the Declarations/References by default, while I think it should default to All Occurrences. I also think that it shouldn't default to what you last used. I think people don't remember what they last used. I do think it would be entirely appropriate to have a prefs option of what you want checked when the search box comes up; "use what I used last time" is a perfectly reasonable option for the prefs.
We currently can't search for all element types, say for methods, fields, types of a given name at the same type. Moving to JDT Core.
(In reply to comment #3) > We currently can't search for all element types, say for methods, fields, types > of a given name at the same type. > > Moving to JDT Core. > This is not true, you can do it using an "Or" SearchPattern. I just released a test in JavaSearchBugTests doing this kind of multiple search in one call: org.eclipse.jdt.core.tests.model.JavaSearchBugTests.testBug221081() So, move back to JDT/UI to decide whether this may be surfaced...
Thanks for the information, Frederic. I wasn't aware of that. So the request would be to replace the radio's in 'Search For' with check boxes.
(In reply to comment #5) > Thanks for the information, Frederic. I wasn't aware of that. > > So the request would be to replace the radio's in 'Search For' with check > boxes. > Yes. And when multiple boxes are checked, create an OrPattern...
It would also be nice if the radio buttons for References/Declarations/Implementors/Occurrences were changed to checkboxes for References/Declarations/Implementors and the radio buttons for Read Access/Write Access be changed to check boxes Basically, let the users get as many results as possible on the first try so that they don't get false negatives. False negatives are baaaaaad. If the user gets too many results, then they can start unchecking boxes on their second try.
The nice thing about the radios is that you can change the option with a single click. If we changed the "Search For" and "Limit To" groups to use checkboxes, I think the 90% case would be that the user unchecks the old options and then checks the new one(s). Doubling the amount of clicks is also baaaaaad ;-) How about just adding a radio "All elements" or "Identifier" in the "Search For" group?
