Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 331581

Summary: Concept work on integrating existing search contributors
Product: [Eclipse Project] e4 Reporter: Dimitar Georgiev <dimitar.georgiev>
Component: SearchAssignee: Dimitar Georgiev <dimitar.georgiev>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: bokowski, danail.branekov, daniel_megert, dimitar.georgiev, hristo.sabev, martina.galabova
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on: 322721, 354972    
Bug Blocks:    

Description Dimitar Georgiev CLA 2010-12-01 13:45:55 EST 
We will start some research on how to integrate existing search contributors inside the incubator search. This bug is to track this initial work - as soon as we have some specific requirements, we can track them separately.

The first shot will be to try and embed existing contributors directly in our search and results views, without requiring further adaptation from clients' end. Let's see if this is feasible.

The work should happen outside the master branch, until we have something stable we want to keep.

Cheers, Dimitar
Comment 1 Danail Branekov CLA 2010-12-10 07:08:32 EST 
After some discussions and eclipse search code analysis we came up to the idea that automatic unconditional integration of existing search features is probably not the best thing to do. Integration would be much more consistent if existing search providers were integrated in search console via an additional "integration layer". The main purpose of this integration layer would be to prevent search console from handling the existing search extension points implicitly. E.g. one’s search contribution will become available in the Search Console only if they have declared their intent to. 

The integration layer's responsibilities would be:
 a. Contribute the artifact types which they are capable to search for (java model elements, files, plugin stuff, etc). This is to provide meaningful display names for them.
 b. Contributors need to provide  a search destination, in order to have a meaningful display name for it. (We were unable to come up with a heuristic that will work for everybody.) Since the larger part of existing searches search in the Local workspace only, we will provide a common “Local Workspace” search destination to be reused by contributors.
 c. Contribute a custom parameters UI implementation. This custom implementation should adapt ISearchPage instances to the designated interface defined by the search console. The adapter implementation should be one and the same for all contributors so the console could implement such a reusable adapter
 d. Contribute a search console search provider whose purpose would be to invoke ISearchPage.performAction() method and present the search result to the user. Again, this implementation should be the same for existing search instances, so the search console could provide such resable implementation

In the end, the integration layer would only contain several extension points contributions and a couple of very simple Java classes. Also, this integration layer is not required to be included in the original search plugins but might be a dedicated integration plugin.
If we take up the above approach, we will also provide a short migration guide. This along with the reusable integration code we will provide should make effort for search contributors minimal. 

The reasoning behind the idea of manual integration of existing searches with the search console is that although the Eclipse search components (search page and search result page) are contributed via two separate extension points, they represent a "black box" for an external component:
 1. The contributed ISearchPage instance only has a method "performAction()". It hides all the search capabilities details (e.g. what does the page search for, what search destinations it supports, etc.)
 2. The ISearchPage interface does not provide means for an integration layer to control the UI state (e.g. enable/disable controls, change the controls content)
 3. The org.eclipse.search.searchPages documentation (http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/search/ui/package-summary.html) says
> your particular search implementation depends on your plug-in's function, but it is typical to open a results viewer in this method using the NewSearchUI method activateSearchResultView().
The statement above means that existing search contributors are advised to invoke some of the _static_ methods of the NewSearchUI class. The NewSearchUI class provides means of controlling the standard eclipse search result UI which is definitely an issue if the search console would integrate current contributors without disturbing them
 4. Existing search implementations may have pretty complext parameters user interface. Therefore, the search console should be able to provide its clients the capability of contributing completely custom parameters user interface, not only an "advanced parameters" section as the current implementation does.

Daniel, I don't know whether you are the right person to ask, but does the manual integration approach look acceptable? Also, we need to deal with NewSearchUI static methods invocations and prevent them from always working with the "Search" view. Any suggestions?
Comment 2 Dani Megert CLA 2010-12-14 06:02:24 EST 
As discussed in our call earlier this year the only way that the Search Console can make it into the SDK is that it replaces the existing Search UI. We won't ship the SDK with two different Search UIs. Therefore there needs to be a layer so that the existing pages work without forcing all search clients to update their existing code in order to continue to function. Also, most products will not have time to invest resources to do that. If that can't be done with the Search Console then we can stop here and you need to offer the Search Console as additional plug-in(s) on top of the SDK.
Comment 3 Dimitar Georgiev CLA 2011-02-12 11:29:38 EST 
Since there has been no activity here, wanted to drop a few words.

@Dani - we agree with your point. We need to have a compatibility story or nobody would adopt us :) . Also it is clearly not a good idea to ship with two search frameworks, so yes, we need a backward-compatible substitute.

We've started some initial work to make platform.discovery even more customizable. This would then allow for embedding the legacy search pages as "custom search UIs" in the framework. Let's see how this goes.
There should be a couple of interesting commits next week to lay the groundwork for the compatibility story, tagged with this bug. Afterwards we can continue the discussion on a more technical level.

We've made sure to take into account
http://wiki.eclipse.org/E4/Compatibility
To us this only means that the search compatibility layer is an optional set of bundles that the very framework is non-dependent on.

Regards, Dimitar
Comment 4 Dimitar Georgiev CLA 2011-02-15 10:25:04 EST 
By design the text field for the search query was actually always created by the framework, which does not work for the case of the compatibility contributors, which will contribute all the search parameters ui as "custom ui" and will have no need of this default search query field.
Therefore the first step here is to factor the whole search parameters ui behind an interface.
This was done by Danail and Martina with https://git.eclipse.org/c/e4/org.eclipse.e4.search.git/commit/?id=e4fddcceab5538b1afc199a3b8d70eca01664dda
Comment 5 Dimitar Georgiev CLA 2011-02-15 11:42:57 EST 
On the other hand of the story, there needs to be code which reads the org.eclipse.search extension points and dynamically creates search console extensions out of them.

The sneak preview of this is implemented with

https://git.eclipse.org/c/e4/org.eclipse.e4.search.git/commit/?id=47c5010de60ead7dc50724fe12b8e1b734b793f7

Now you will see all search page  display names in the "Search for" dropdown. Of course you can still do nothing with them because there is no extension yet to contribute the search ui or perform the search.

Regards, Dimitar
Comment 6 Dimitar Georgiev CLA 2011-02-15 11:48:55 EST 
P.S. We decided to drop the branch approach i mentioned in the beginning of this bug. The commits are to master. The advantage is we can get feeedback from the e4 team directly after the integration builds. The disadvantage is we may potentially introduce unstable content, but we have no clients to break yet, so pros outweigh the cons.
Comment 7 Dimitar Georgiev CLA 2011-07-03 08:28:44 EDT 
(In reply to comment #6)
> P.S. We decided to drop the branch approach i mentioned in the beginning of
> this bug. The commits are to master. The advantage is we can get feeedback from
> the e4 team directly after the integration builds. The disadvantage is we may
> potentially introduce unstable content, but we have no clients to break yet, so
> pros outweigh the cons.

Concerning the above comment, we've moved the 'compat' bundle to a separate feature, so its installation is optional. This way clients who do not care about the compat bundle will not be disturbed.

On another note, the search parameters UI is hidden behind a dedicated interface
https://git.eclipse.org/c/e4/org.eclipse.e4.search.git/commit/?id=6faede41fb163bfeb8c1c123bc5ad4542bc72f9a

The next steps are:

- create an extension point where users can contribute a custom search UI through the new interface
- Compatibility bundle reads the legacy searchPages extension point and contributes dynamically to the custom search ui extension point, using a implementation which delegates to ISearchPage implementations

We have an issue with the "destination category" / "destination" concept - these are the things next to the "Search in" label in the UI. The legacy contributions are a black box to us, so there is no way to know where they "search in".
Maybe it will make sense to allow some kind of 'null' destination category and destinations provider.
Possibly, such null destinations can be made non-renderable in the UI. The end user effect will be that when you select to "Search for" one of the legacy object types, the "Search in" controls will e.g. dissapear, or become empty/diabled.
Comment 8 Dimitar Georgiev CLA 2011-09-01 09:18:28 EDT 
Hi Folks,

We have implemented a throw-away prototype which proves the concept that existing search extensions can be successfully hosted in Search Console, without modification of the extensions' code.
Although far from perfect, it is fully functional.

Can you please check it out and contribute thoughts / opinions / issues you run into?

<<HOW TO TRY IT OUT>>
1. Fetch to head of the "prototype" branch
https://git.eclipse.org/c/e4/org.eclipse.e4.search.git/commit/?h=prototype&id=2905a7030e0edecb83337c3a02a7cd0e25954ae4
2. Launch a runtime workbench.
3. Window -> Show View -> Search Console.

There have been a couple of issues that the proposed prototype fails to address. We need to tackle these if we are to productize the implementation.

1)When one searches in Search Console using a org.eclipse.search contribution, the org.eclipse.search results UI activates.
This is not the intended behaviour.

The issue stems from the fact that ISearchPage extensions call the NewSearchUI.runQuery...() static methods in their performAction() method, which in turn results in

		// prepare view
		if (view == null) {
			getSearchViewManager().activateSearchView(true);
		} else {
			getSearchViewManager().activateSearchView(view);
		}
		
I failed to find a way around this, besides modification of the NewSearchUI code.
A simple way to handle this is to somehow let the NewSearchUI know it is called in a context where the result view should not be activated. 
Please comment whether this is feasible and how you think it should look like. If we have a few pointers, I can propose a patch.

2) Secondly, what is the intended behaviour if one e.g. starts a "File" search from the Search Console, and the search result view IS already opened?
Should it populate with the search results from the query, as it does now, or should we also prevent this too?

Looking forward to any comments and suggestions.

Best Regards, Dimitar
Comment 9 Dani Megert CLA 2011-09-23 05:31:42 EDT 
Cool, that the existing searches can be integrated - this is a good step forward!


> 1)When one searches in Search Console using a org.eclipse.search contribution,
> the org.eclipse.search results UI activates.
> This is not the intended behaviour.

I agree. How about adding a 'Replace Search view with Search Console' preference to the 'Search' page? That way we can redirect all searches to the Search Console, including searches that are currently not done via Search dialog.


> 2) Secondly, what is the intended behaviour if one e.g. starts a "File" search 
> from the Search Console, and the search result view IS already opened?
> Should it populate with the search results from the query, as it does now, or 
> should we also prevent this too?

I would expect that by default it displays in the Search Console. I guess I would use the preference from 1) and only if people really like to mix the views, we add an additional preference for people that like the non-modal way of starting a search but prefer to see the results in the Search view.


Here my comments to the prototype. I did not look at any code at this point.

LAF
===
- Why is the right side (result) shown in a tab? I could not find a way to get 
  multiple-tabs. If it is not possible to get multiple tabs, then this should be
  removed as it wastes real estate.

- The 'Scope' part is missing in all searches.

- The 'Search in' area is not used by the existing searches but still uses up
  lots of space. We should hide it in those cases. This would also get rid of
  the name conflict as 'Search In' is already used by the existing search pages 
  (e.g. Java Search).

- The search area is too narrow and I was not able to make it bigger. The UI
  should not try to enforce a size on me.

- Besides being too narrow, there isn't a horizontal scrollbar to workaround
  this and hence I cannot reach some of the UI controls.

- The view should have the standard 'Layout' view menu (see e.g. Type Hierarchy
  view) which allows to switch between horizontal, vertical and automatic
  layout. I could imagine that a 'Query Only' or 'Input Only' mode could
  be useful: one could use the Search Console view solely to enter the input and
  then display the result in the Search view.
  I suspect that for the existing searches, the horizontal layout will be a 
  better fit.

- The vertical sash looks too heavyweight to me.

- I don't like the bluish background (I tested on top of 3.8 M2) - it makes the
  view look like a contaminant.

- Searches done directly on an element (e.g. search for references via context
  menu) should also end up in the Search Console. For that to work we need the
  preference I mentioned above.

- It looks awkward that the view toolbar items are not in the view but in a tab.
  This should be changed.

- I think the feature to choose which searches are shown ('Customize...' button
  in the Search dialog) is a good one. We should try to share that data between
  the dialog and the Search Console (probably needs new API in
  'org.eclipse.search').

- Switching between searches via combo box is harder than just clicking a tab.
  Maybe we could offer tabs as alternative?

- view category: if we add a new one then we should label it "Search" and add
  the existing searches to it as well.


Bugs
====
- 'Manage Destinations' opens an empty filtered preference dialog.

- Using Up/Down Arrow when in the combo box should not remove the focus from the
  combo box.

- Selecting 'Java AST Search' gives a CCE, see [1].

- Some of the searches cause an IAE, see [2]. Those are using the old Classic
  Search view.

- Some of the view menus are not in the correct order.

- Some of the general search view toolbar actions are missing (history, pin,
  refresh, stop).

- I don't like the "discovery" in the project and package names. Why not  use
  'org.eclipse.searchconsole.*' or  'org.eclipse.search.console.*'?

- org.eclipse.cheatsheets.* is not OK. Should be something like
  org.eclipse.searchconsole.cheatsheets, so that the origin is clearer.


[1]
!ENTRY org.eclipse.jface 4 2 2011-09-23 09:20:08.613
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface".
!STACK 0
java.lang.ClassCastException: org.eclipse.swt.layout.GridData cannot be cast to org.eclipse.swt.layout.FormData
	at org.eclipse.swt.layout.FormLayout.layout(FormLayout.java:293)
	at org.eclipse.swt.layout.FormLayout.computeSize(FormLayout.java:241)
	at org.eclipse.swt.widgets.Composite.computeSize(Composite.java:233)
	at org.eclipse.swt.layout.FormData.computeSize(FormData.java:117)
	at org.eclipse.swt.layout.FormData.getWidth(FormData.java:146)
	at org.eclipse.swt.layout.FormData.getRightAttachment(FormData.java:248)
	at org.eclipse.swt.layout.FormLayout.computeWidth(FormLayout.java:266)
	at org.eclipse.swt.layout.FormLayout.layout(FormLayout.java:332)
	at org.eclipse.swt.layout.FormLayout.computeSize(FormLayout.java:241)
	at org.eclipse.swt.widgets.Composite.computeSize(Composite.java:233)
	at org.eclipse.ui.forms.widgets.LayoutComposite.computeSize(LayoutComposite.java:35)
	at org.eclipse.swt.widgets.Control.computeSize(Control.java:614)
	at org.eclipse.platform.discovery.ui.internal.view.SearchConsoleView$7.notifyComplete(SearchConsoleView.java:409)
	at org.eclipse.platform.discovery.ui.internal.view.SearchProviderSelector$1.objectTypeSelected(SearchProviderSelector.java:74)
	at org.eclipse.platform.discovery.ui.internal.view.impl.SearchForSelectionChangeListener.selectionChanged(SearchForSelectionChangeListener.java:33)
	at org.eclipse.jface.viewers.Viewer$2.run(Viewer.java:164)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
	at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
	at org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:162)
	at org.eclipse.jface.viewers.StructuredViewer.updateSelection(StructuredViewer.java:2188)
	at org.eclipse.jface.viewers.StructuredViewer.handleSelect(StructuredViewer.java:1211)
	at org.eclipse.jface.viewers.StructuredViewer$4.widgetSelected(StructuredViewer.java:1241)
	at org.eclipse.jface.util.OpenStrategy.fireSelectionEvent(OpenStrategy.java:239)
	at org.eclipse.jface.util.OpenStrategy.access$4(OpenStrategy.java:233)
	at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:403)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4165)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3754)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:624)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:579)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1431)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1407)

[2]
!ENTRY org.eclipse.jface 4 0 2011-09-23 09:27:11.954
!MESSAGE Unhandled event loop exception during blocked modal context.
!STACK 0
org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not match outer scope rule: org.eclipse.platform.discovery.compatibility.internal.container.OperationRunnerToRunnableContextAdapter$MutexSchedRule@1d79538)
	at org.eclipse.swt.SWT.error(SWT.java:4283)
	at org.eclipse.swt.SWT.error(SWT.java:4198)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4140)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:173)
	at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:388)
	at org.eclipse.platform.discovery.util.internal.longop.ModalContextLongOpRunner.runInModalContext(ModalContextLongOpRunner.java:103)
	at org.eclipse.platform.discovery.util.internal.longop.ModalContextLongOpRunner$ModalThreadForker.runInNewThread(ModalContextLongOpRunner.java:73)
	at org.eclipse.platform.discovery.util.internal.longop.SingleForkThreadRunner.run(SingleForkThreadRunner.java:41)
	at org.eclipse.platform.discovery.util.internal.longop.SchedulingRuleSynchRunner.run(SchedulingRuleSynchRunner.java:44)
	at org.eclipse.platform.discovery.util.internal.longop.ModalContextLongOpRunner.run(ModalContextLongOpRunner.java:45)
	at org.eclipse.platform.discovery.compatibility.internal.contributors.impl.searchprovider.CompatibilitySearchQuery.execute(CompatibilitySearchQuery.java:64)
	at org.eclipse.platform.discovery.core.internal.SearchConsoleController$SearchEventHandler.executeQuery(SearchConsoleController.java:209)
	at org.eclipse.platform.discovery.core.internal.SearchConsoleController$SearchEventHandler.handleSearch(SearchConsoleController.java:198)
	at org.eclipse.platform.discovery.core.internal.SearchConsoleController.search(SearchConsoleController.java:90)
	at org.eclipse.platform.discovery.ui.internal.view.SearchConsoleView.search(SearchConsoleView.java:626)
	at org.eclipse.platform.discovery.ui.internal.view.SearchConsoleView.access$9(SearchConsoleView.java:618)
	at org.eclipse.platform.discovery.ui.internal.view.SearchConsoleView$10.widgetSelected(SearchConsoleView.java:689)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:240)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4165)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3754)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:624)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:579)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1431)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1407)
Caused by: java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not match outer scope rule: org.eclipse.platform.discovery.compatibility.internal.container.OperationRunnerToRunnableContextAdapter$MutexSchedRule@1d79538
	at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63)
	at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:134)
	at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:333)
	at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:63)
	at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:286)
	at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:118)
	at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:2282)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2339)
	at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118)
	at org.eclipse.platform.discovery.compatibility.internal.container.OperationRunnerToRunnableContextAdapter$1.run(OperationRunnerToRunnableContextAdapter.java:34)
	at org.eclipse.platform.discovery.compatibility.internal.container.OperationRunnerToRunnableContextAdapter$1.run(OperationRunnerToRunnableContextAdapter.java:1)
	at org.eclipse.platform.discovery.util.internal.longop.SchedulingRuleSynchRunner$RuleSynchronizingDecorator.run(SchedulingRuleSynchRunner.java:59)
	at org.eclipse.platform.discovery.util.internal.longop.SingleForkThreadRunner$ThreadTrackingDecorator.run(SingleForkThreadRunner.java:78)
	at org.eclipse.platform.discovery.util.internal.longop.ModalContextLongOpRunner$1.run(ModalContextLongOpRunner.java:117)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Comment 10 Danail Branekov CLA 2011-09-26 03:33:58 EDT 
Thanks for the detailed input, Dani!

>I agree. How about adding a 'Replace Search view with Search Console' preference to the 'Search' page? That way we can redirect all searches to the Search Console, including searches that are currently not done via Search dialog.
Well, I think that this would be awkward for users if they start the search from the console and get the result in the results view. The other way round (starting the search in the existing search dialog and getting the results in the console) is also confusing. I think that the most elegant option would be that the NewSearchUI to have something like a context via which to know which result UI to activate

>Why is the right side (result) shown in a tab? I could not find a way to get multiple-tabs. If it is not possible to get multiple tabs, then this should be removed as it wastes real estate
Search implementations are capable of displaying results of subsequent searches in another tab. For example, the user could select an e.g. "Further details" context menu item. If proper implementation is supplied, the further details could be displayed in another tab.
The layer which integrates the current search functionality is not aware of the searches it integrates and therefore such a feature cannot be provided in a generic manner

>The 'Scope' part is missing in all searches
Scope part can be introduced as "custom parameters" user interface which the integration layer can supply later on. The intent of the prototype Dimitar implemented is to show that integration is possible at all

>The 'Search in' area is not used by the existing searches but still uses up lots of space. We should hide it in those cases. This would also get rid of the name conflict as 'Search In' is already used by the existing search pages (e.g. Java Search)
Agree! This is something we have been discussing recently. The approach we are thinking is to show the "Search In" stuff only when necessary

>- The search area is too narrow and I was not able to make it bigger. The UI should not try to enforce a size on me.
>- Besides being too narrow, there isn't a horizontal scrollbar to workaround this and hence I cannot reach some of the UI controls.
Yes, search parameters UI should be scrollable. However, this is some UI polishing which is to be implemented in the "productive" implementation. As I mentioned above, this is not the intent of the prototype

>The view should have the standard 'Layout' view menu (see e.g. Type Hierarchy view) which allows to switch between horizontal, vertical and automatic layout. I could imagine that a 'Query Only' or 'Input Only' mode could be useful: one could use the Search Console view solely to enter the input and then display the result in the Search view.
> I suspect that for the existing searches, the horizontal layout will be a better fit.
The "Results only" view is kind of possible currently - if you click on the button which is next to the sash, the parameters UI is hidden and only results are displayed. Clicking it again reveals the paraters again.
Your proposal to let the user decide the layout makes much sense from my point of view. 

>The vertical sash looks too heavyweight to me
What do you mean - you observe performance or usability issues?

>I don't like the bluish background (I tested on top of 3.8 M2) - it makes the view look like a contaminant.
The bluish background was a requirement from our usability experts. In fact we (most of the developers) don't like it either :)

> It looks awkward that the view toolbar items are not in the view but in a tab.
> This should be changed.
The idea of this approach is that each results tab has its own toolbar items/menus so that the "master" toolbar content of the view is independend from the current result tab

> I think the feature to choose which searches are shown ('Customize...' button in the Search dialog) is a good one. We should try to share that data between the dialog and the Search Console (probably needs new API in 'org.eclipse.search')
Yes, makes sense

>  Switching between searches via combo box is harder than just clicking a tab. Maybe we could offer tabs as alternative?
Any suggestions are welcome :)

> 'Manage Destinations' opens an empty filtered preference dialog.
Search providers can specify the preference page via which they are configured. This feature is not used by the cheat sheets search and this is why an empty preference page is displayed. However, the intent is when the user clicks on the link to get a preference dialog with all preference pages which can configure existing search provider.
Current searches do not specify such a preference via interface methods and therefore such preferences filtering is probably impossible

> I don't like the "discovery" in the project and package names. Why not  use
>  'org.eclipse.searchconsole.*' or  'org.eclipse.search.console.*'?
"Discovery" naming was introduced in the SAP eclipse distribution. Renaming the plugins/packages should not be a problem

> org.eclipse.cheatsheets.* is not OK. Should be something like
>  org.eclipse.searchconsole.cheatsheets, so that the origin is clearer.
Renaming should not be a problem as well


Thanks!

Regards, Danail
Comment 11 Dani Megert CLA 2011-10-03 09:13:00 EDT 
> I think that the most elegant option would be
> that the NewSearchUI to have something like a context via which to know which
> result UI to activate
How would that work i.e. how would those contexts be chosen? Do you have more details and examples?


> The layer which integrates the current search functionality is not aware of the
> searches it integrates and therefore such a feature cannot be provided in a
> generic manner
Right, but I assume that we know which ones support it. For those who don't support it, we should not waste the real estate.

>>The vertical sash looks too heavyweight to me
>What do you mean - you observe performance or usability issues?
Usability : it is too wide - looks ugly.

> The idea of this approach is that each results tab has its own toolbar
> items/menus so that the "master" toolbar content of the view is independend
> from the current result tab
I don't like to introduce yet another level of toolbars. Having global + part toolbars should be enough.

>>  Switching between searches via combo box is harder than just clicking a tab. > Maybe we could offer tabs as alternative?
> Any suggestions are welcome :)
Tabs ;-)
Comment 13 Eclipse Genie CLA 2019-03-15 11:55:39 EDT 
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.