Bug 38062 [api] Provide API that allows to use text search for a new search (page)
Use case: I wanted to take the basic TextSearch and change the LabelProvider in TextSearchResultCollector.aboutToStart(), since the one used there, FileLabelProvider(FileLabelProvider.SHOW_LABEL_PATH), displays filenames and java-related icons, while we wanted to display text and icons based on our Model. The LabelProvider I wanted to use is < 60 loc (incl. javadocs). In order to create a SearchPage, one must: (1) do some things with plugin.xml (no problem); (2) write a class that extends DialogPage and implements ISearchPage ... I thought it would be simple to copy the existing org.eclipse.search.internal.ui.text.TextSearchPage class, and simply replace the LabelProvider -- but in fact the LabelProvider is only created down in TextSearchResultCollector, so I would have to copy that too: Problem: TextSearchPage has the following dependencies, in packages org.eclipse.search.internal.{core, ui}.text, that are *not* public: TextSearchOperation (public) TextSearchEngine (core) (public) TextSearchVisitor (core) (public) AmountOfWorkCalculator (core) (public class, but package ctor) TypedResourceVisitor (core) (public class, but package ctor) TextSearchResultCollector (public) GroupByKeyComputer (package class, public method) GotoMarkerAction (package class, public method) TextSearchActionGroup (package class, public ctor) ReplaceAction (package class, public ctor) ReplaceDialog (public class, protected ctor) Which means that in order to plug in a new LabelProvider (of 60 loc), I had to copy eleven classes (totalling over 1700 lines), plus of course the TextSearchPage itself (almost 600 lines). Suggestions: a) Provide a public ctor, with a parameter LabelProvider, for class TextSearchResultCollector (perhaps defaulted via ctor-chaining, so that the current code of TextSearchPage could remain unaltered); then client code could simply copy the TextSearchPage, change the LabelProvider to be the one desired, and all would be well; b) Provide a new extension point (unclear to me exactly how, but surely it is possible) that would allow clients to specify that their SearchPage would use TextSearchPage (or any existing class -- clearly the current extension point can do that already), but that *also* allows clients to specify a second class, their LabelProvider -- then clients would not even have to copy the 600 lines of TextSearchPage
org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/propertiesfileeditor/PropertyKeyHyperlink.java
}
		open(references);
	}
	private boolean checkEnabled() {
		 
		return fStorage instanceof IResource;
	}
	private void open(KeyReference[] keyReferences) {
		Assert.isLegal(keyReferences != null && keyReferences.length > 0);
		if (keyReferences.length == 1)
			open(keyReferences[0]);
		else
			open(select(keyReferences));
	}
	/**
	 * Opens a dialog which allows to select a key reference.
	 * <p>
	 * FIXME: The lower pane is currently not sorted due to https://bugs.eclipse.org/bugs/show_bug.cgi?id=84220
	 * </p>
	 *
	 * @param keyReferences the array of key references
	 * @return the selected key reference or <code>null</code> if canceled by the user
	 */
	private KeyReference select(final KeyReference[] keyReferences) {
		Arrays.sort(keyReferences);
		final int length= keyReferences.length;
		ILabelProvider labelProvider= new WorkbenchLabelProvider() {
			public String decorateText(String input, Object element) {
				KeyReference keyRef= (KeyReference)element;
				IStorage storage= keyRef.storage;