Community
Participate
Working Groups
Created attachment 77067 [details] Screen shot of proposed FindInTreeDialog Build ID: M20070212-1330 This is an enhancement request to provide a generic Find Dialog for TreeViewers with similar ( but limited ) functionality that is provided by the Find/Replace Dialog that is available for text viewers. I think this is something that is lacking in most GUI toolkits and would be a great enhancement for Eclipse developers. If you have massive amounts of data in a tree, it's quite necessary to have. I have some code that provides this functionality and works quite well and has excellent performance. If anyone is interested, I will post it. I would gladly contribute the code and work on whatever issues come up. It consists of a FindInTreeDialog class which the caller would supply an IFindAction interface which gets invoked when the Find button is pressed. I also have an implementation of the IFindAction which will work on any TreeViewer using an ITableLabelProvider and ITreeContentProvider. I attached a screen shot of the proposed dialog. Notice the Scope group contains 2 checkboxes. These checkboxes are dynamic and are created based on the column names that the user provides and considers to be "searchable" columns. These selections along with all the other parameters are then passed to the IFindAction when the Find button is pressed.
Not sure if this would be a good idea but I cannot really tell why. Assigning to Kevin for comment...
I agree that the problem is important and needs addressing. Thanks for the offer of code and help. Another approach is described in bug #69200. I prefer this approach because its a little less obtrusive having an inplace search rather than a non-modal dialog. Its perhaps not as feature rich as your suggestion though, and yours may be easier to patch into current viewers. On a related note, we are also interested in going the Firefox route of in-place search area at bottom of editors rather than the current dialog. My personal bias is against dialogs for searching because they block the area you're trying to search.
Good point. I am in favor of the no dialog approach too. Can we do the same for text editors as well or at least have the option? Don't know how all the functionality would be addressed with the in-place search area. I guess one could still have the find/replace comboboxes and all the checkbox options?
I think we can consider this a duplicate of bug 69200, since the modern convention is to have a shared "quick find" bar rather than a dialog. Barry, I think this is something we'll consider in the e4 timeframe. Do you have interest in contributing in this area? If so, please comment in bug 69200. *** This bug has been marked as a duplicate of bug 69200 ***
