Bugzilla – Full Text Bug Listing
| Summary: | scope search from editor | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | libing wang <libingw> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse.felipe, john.arthorne, libingw |
| Version: | 0.3 | ||
| Target Milestone: | 0.4 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Susan McCourt
Yes. More generically, we may want this kind of scope to be valid on any page that has a "clue"/bread crumb where we are. We should also make the scope consistent for file name search. John, I think server supports location on name search but please correct me if otherwise. Also, as we are talking about search in the editor now, I would like opinions on "CTRL+H". It gives a quick overlay of result and you can switch to different files but I am always lost after several clicks. I have to navigate multiple times back to my original file. Not sure if we should just open another tab for the result page. search in the editor: ctrl J - incremental ctrl F - find ctrl H - file search I particularly don't like the UI for ctrl+H, it is not consistent with the Ctrl F and Ctrl J. The file search in the editor page is not consistent with the file search in the navigator page (in the navigator page there is no Ctlr H, dialog, and overlay list). Note also that Ctrl+H hides the browser show history shortcut. I also have a hard time to remember how to get the list of shortcuts: ctrl+shift+l -> editor shift+? -> navigator other pages? It would be nice to make that consistent across our pages (should I open a separate bug ?) (In reply to comment #2) > I also have a hard time to remember how to get the list of shortcuts: > ctrl+shift+l -> editor > shift+? -> navigator > other pages? > It would be nice to make that consistent across our pages > (should I open a separate bug ?) done Bug 366845. it would be great to fix this for 0.4. I still think scoping to the project is the best idea, but if that proves difficult, scoping to the parent folder at least puts us in a search results page that will then let us move upward. (In reply to comment #4) > it would be great to fix this for 0.4. > I still think scoping to the project is the best idea, but if that proves > difficult, scoping to the parent folder at least puts us in a search results > page that will then let us move upward. I will try to make it for RC1 on project level. Ideally search should be scoped where ever there is a breadcrumb. And when the bread crumb is generate, the create should "flag" which segment is the search scope. Otherwise the tail segment will always the scope. (In reply to comment #5) > I will try to make it for RC1 on project level. > Ideally search should be scoped where ever there is a breadcrumb. And when the > bread crumb is generate, the create should "flag" which segment is the search > scope. Otherwise the tail segment will always the scope. agree. I've got that covered in bug 349531. Ideally what happens (in 0.5) is a page uses API like setPageTarget(itemMetadata, breadcrumb href function, etc....) and then what happens is: - correct breadcrumb is generated - "related pages" menu is generated - search is scoped - etc... (In reply to comment #6) > (In reply to comment #5) > > I will try to make it for RC1 on project level. > > Ideally search should be scoped where ever there is a breadcrumb. And when the > > bread crumb is generate, the create should "flag" which segment is the search > > scope. Otherwise the tail segment will always the scope. > > agree. I've got that covered in bug 349531. > Ideally what happens (in 0.5) is a page uses API like > > setPageTarget(itemMetadata, breadcrumb href function, etc....) > > and then what happens is: > - correct breadcrumb is generated > - "related pages" menu is generated > - search is scoped > - etc... Cool. Fixed with http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=54aef56093354ece9b7a6830122a5ba6f08aa90d. Scoping to the parent folder is actually better because you get faster response at first shot. Once in the search page you can just scope up by another click on the bread crumb. I also change the default hint "Search root" to "Search". If you are in a page with bread crumb(navigator, git log, editor and search for now)and file system root is presented, the hint will show "Search {file serverce name}". E.g. "Search Orion Projects". For all the other pages we should also hint"Search {file serverce name}" but we will fix that in common code in 0.5. I will open a bug on that. (In reply to comment #8) > For all the other pages we should also hint"Search {file serverce name}" but we > will fix that in common code in 0.5. I will open a bug on that. Opened Bug 370872. |