Community
Participate
Working Groups
There have been numerous discussions regarding the desire to have a "common search box" in the eclipse workbench. There are a number of bugs surrounding the implementation of said box, but I don't think we have a bug anywhere that captures what kind of search should be supported in the workbench. - are we saying there should be a common search bar? - does it have selectable search engines a la firefox search bar? - where does it live visually? (in the trim? in the title bar on win7/cocoa? etc....) and most importantly: What does a common search box do in Eclipse? - several people have said this search box should support Ctrl-3 "quick access" style navigation. So that you could always type the name of any command/dialog/part you were looking for and quickly find it. This seems to be a favorite of Eclipse developers - Surely there is a bug asking for firefox-style text find/replace in the eclipse editors. Do we have such a bug? Do we think this would be implemented with a common search bar (or this is more of an editor thing?) - Are there existing platform search bugs where a common search bar has already been discussed? - Bug 69200 talks about common search for lists and trees. One might imagine a search box operating on the active part. - What is the relationship (if any) between this common search bar and the existing search extension points? Would it be useful/possible to present the existing searches in this search bar somehow? How would the user specify the search parameters besides text that are currently shown in the dialog? Maybe only those searches for which there are reasonable defaults should live in this bar. - Is there an extension point by which plug-ins can contribute their own kind of "simple search" and is this related at all to the existing search extension points? Please mark any relevant bugs that should be considered as blocking bugs so we can understand the various requirements.
To kick things off, here is my personal opinion: > - are we saying there should be a common search bar? +1 > - does it have selectable search engines a la firefox search bar? +1 > - where does it live visually? (in the trim? in the title bar on win7/cocoa? no preference > What does a common search box do in Eclipse? I would like to have it support many search providers (similar to the Firefox search box). This would make things like Ctrl-3 but also "Open Type"/"Open Resource" better discoverable. The current key binding for these could assign keyboard focus to the search box and select the right search provider. Not sure what the default search provider should be for the Eclipse IDE - perhaps "Open Resource"? > - Surely there is a bug asking for firefox-style text find/replace in the > eclipse editors. Do we have such a bug? Do we think this would be implemented > with a common search bar (or this is more of an editor thing?) I don't think this would be appropriate, it's more of an editor thing and Firefox does not use its search box for finding text in the current page - it grows a separate search area in the trim. > - Bug 69200 talks about common search for lists and trees. One might imagine a > search box operating on the active part. Similar to the above, I think it is important to have searches that operate on a part be local to that part. > - What is the relationship (if any) between this common search bar and the > existing search extension points? Would it be useful/possible to present the > existing searches in this search bar somehow? How would the user specify the > search parameters besides text that are currently shown in the dialog? Maybe > only those searches for which there are reasonable defaults should live in this > bar. Not sure, but one possibility would be to allow search queries in the search box, with further refinement (where you'd want a forms-based UI similar to the current one) being triggered from the place where you see the search result. > - Is there an extension point by which plug-ins can contribute their own kind > of "simple search" and is this related at all to the existing search extension > points? Not sure if related, but I would like to see this be extensible. "Open Type" and "Open Resource" would be contributions to this extension point.
I completely agree with Boris. To state my opinion: > - are we saying there should be a common search bar? +1 > - does it have selectable search engines a la firefox search bar? +1 This should definitely be extensible. "Open Type" and "Open Resource", and "Text Search" would be contributions to this extension point.
(In reply to comment #0) > - are we saying there should be a common search bar? +1 > - does it have selectable search engines a la firefox search bar? -0.5 > - where does it live visually? (in the trim? in the title bar on win7/cocoa? > etc....) no preference, it should be a prominent location, though > What does a common search box do in Eclipse? I like the concept of multiple search providers. However, I dislike the concept of manually selecting the search provider. Therefore I voted "-0.5" above. If you look at the future of browsers the search bar merges with the address/location bar to become a global navigation bar. This Eclipse search bar should go into a similar direction. As a lazy user I just start typing in the bar. "IAdap<cursor>". As soon as I pause a bit auto completion kicks in and comes back with a few proposals. * IAdaptable.java - org.eclipse.equinox.common/src/... (Open in Editor) * Class org.eclipse.core.runtime.IAdaptable (Open JavaDoc) * MyAdapter.java - myproject/src/.... (Open Editor) * plugin.xml - myproject (Open Editor) * Adapters (Eclipse Help) * org.eclipse.core.runtime (Eclipse Platform API Specification) * Search for references to org.eclipse.core.runtime.IAdaptable * Search help for "IAdap" * Search workspace for files containing "IAdap" * ... > - What is the relationship (if any) between this common search bar and the > existing search extension points? Ideally, I would stop using existing searches (Ctrl+H) but only use the search bar and find what I want quickly. > Would it be useful/possible to present the > existing searches in this search bar somehow? As I outline above, existing search could be integrated into the search bar using search actions. For example, I type something, JDT recognizes that this could be a Java class and offers me an "action" to search for references. Similar, another "action" would allow me to start a file search. > How would the user specify the > search parameters besides text that are currently shown in the dialog? Maybe > only those searches for which there are reasonable defaults should live in this > bar. +1 > - Is there an extension point by which plug-ins can contribute their own kind > of "simple search" and is this related at all to the existing search extension > points? +1 for allowing others to contribute results to the search bar. Such results could be other "actions" or real search results. FWIW, I could imagine that one day the common search bar is connected to an index (likely Lucene). The index is filled by many providers. The search bar could become something like a desktop/Google search scoped to the SDK and its content. Everything is indexed and I get results quickly. Results a ranked properly. Eventually this index will be hooked into desktop search engines.
I'm a definite +1 for this. Funny though, we discussed something like this about 4-5 years ago with a proposal, just can't find it now.
+1, such a search field is definitely something to explore further. I agree with Boris, that editor/text search is different/separate from that and some investigation (tough stalled at this time) has already been done, see bug 99294. Currently we already have two extension points for searches: one in Platform Search and another one in Platform UI (help). If there's a way to somehow reuse that, it would be good. Regarding Open Type and Open Resource: there's already a feature request that wants to marry the two, see bug 279624. Another interesting question is how we would present the matches: would the search bar show the matches so that a single result can be selected or would it simply feed the search string into the appropriate dialogs and/or views (e.g. Open Type dialog, Search view, etc.)? If this feature would allow to present results then it might find matches using several plugged-in search providers, e.g. resources and types starting with "Foo".
(In reply to comment #5) > Another interesting question is how we would present the matches: would the > search bar show the matches so that a single result can be selected or would it > simply feed the search string into the appropriate dialogs and/or views (e.g. > Open Type dialog, Search view, etc.)? If this feature would allow to present > results then it might find matches using several plugged-in search providers, > e.g. resources and types starting with "Foo". I think that there should be some "auto-completion" like presentation to the user (while a user is typing in the search bar) - similar to browsers. Up/Down arrow keys could be used to navigate the quick results and Enter/Return "opens"/"invokes" the result. The presentation should be prepared for some richer styling of the "quick" results (eg. some text formatting, an icon, etc.). This would be useful to differentiate the different kind of results, eg. a search action would have a search icon in front of the text, an editor result could have the corresponding editor icon, a command the command icon. Some result might open editors directly. Others are "actions" which (upon its invocation) start a search which populates the search results view (like find references for example).
I really like where Gunnar and Dani are going with this - minimizing user choice of search engines and merging results. There could still be some preferences to guide which searches are active, or perhaps priority when showing results.
(In reply to comment #7) > There could still be some preferences to guide which searches are active, > or perhaps priority when showing results. Yes, feedback (for ongoing background operation) as well as ranking is important. For example, results from JDT searchers should be ranked higher in a JDT perspective. A more advanced ranking algorithm might also boost results from PDE searches even though a JDT perspective is active but a PDE project is selected or a PDE editor is active. Hmmm .... so much possibilities. :)
I have been thinking for a few years now about the "search service" that would be a part of the platform. Actually, the "token viewer" (https://bugs.eclipse.org/bugs/show_bug.cgi?id=262846) was a byproduct of one of the prototype implementations (they all failed for me :) but I'm meaning to start anew). I believe modern UI relies heavily on search - we can see it as Spotlight on Mac, whatever rip-off they have on Windows. Searchboxes are everywhere. The IDE really relies on search for stuff like content assist, open type/resource/etc. Having "search service" would allow decoupling UI from the search logic itself. Here are some of the requirements for the search service I gathered: 1. Search engine is not a part of the UI. There are several UI elements that may consume it (toolbar searchbox, content assist processors, "Open Resource" dialog, a lot of application-specific UIs) but it may also make sense for non-UI parts like refactoring support. It may also be great for reuse in web-based applications. 2. It should provide object agnostic API. I.e. it should not specifically search for Java elements, resources, company employees (in RCP application). 3. It should not need to rely on a workspace. RCP application may use it to search for apples, oranges, whatever. 4. It should be extensible. Default implementation of the "resource search processor" may find files based on file name - while plugin may contribute to the same search results to search by author. 5. It should have consistent and extensible query language (plain text match, camelcase, comparison), support for arbitrary attributes (author:"John Doe") 6. I should be possible to restrict search scope (i.e. based on working set, object type, "department"). 7. It should also have an extensible UI part (i.e. label providers for the search results - that will work in both content assist pop-ups and searchbox). 8. It should have high-performance (i.e. it should be able to invoke "search processors" concurrently and asynchronously) while maintaining simple programming model for both extension and consumption. 9. It should provide session management, when several concurrent sessions may be under way (i.e. search processors backed by database may opt to avoid requiring database if next search narrows down previous - i.e. if we have results for employees named "Jo" we need only filter out some of them if next query is "Joh" - that can be done without going to the backend.
Re-assigning to the 'e4' stream...
(In reply to comment #9) > I have been thinking for a few years now about the "search service" that would > be a part of the platform. Thanks Eugene, your requirements list is very useful. Do you think there is anything we could do in short order, for the July release? What's the simplest thing that could possibly work?
in bug 293481 comment 37 there is a request that the user can eliminate the search bar from the toolbar if they don't want it. Also discussion about left vs. right positioning. We would probably give configurability to the search bar similar to perspective bar (dock on-> ???)
I'm going to take a stab at something bare bones/non-extensible. My fantasy idea is that: - the filter box in the QuickAccessDialog can be separated from the rest of it, so that typing in the search box would give you a categorized popup like quick access - somehow merge open resource into the search If this can't be done then I will probably fall back to the selectable search and these two kinds of search would be treated separately, but both available from the box. If this can't be done then there will be no search box in 4.0.
I have released changes to HEAD for putting a search box in the trim. It currently has the Quick Access functionality only. I am not sure if I will have the time to also get "open resource" functionality in there. Also high on my list is to port the "new look" non-native search control from FilteredTree, because the search box only looks like a search box on the Mac and on GTK.
>Also high on my list is to port the "new look" non-native search control from >FilteredTree I think the best thing is to provide a FilterText or SearchText widget. We also have the need for such a widget in 3.7.
Moving open bugs to a target milestone that is not in the past. Please adjust target as you see fit.
>I think the best thing is to provide a FilterText or SearchText widget. We also >have the need for such a widget in 3.7. See bug 293230.
(In reply to comment #17) > >I think the best thing is to provide a FilterText or SearchText widget. We also > >have the need for such a widget in 3.7. > See bug 293230. We won't have the cycles to work on an emulated widget for the 4.0 search box in time for the release, but if anyone else has time, feel free to provide a patch... :-)
marking bug fixed since work was done and milestone is recorded. Opened bug 320529 to track the evolution of this feature (and point to this bug since other ideas were captured.) Of course anyone can open a specific bug for specific suggestions...
