Community
Participate
Working Groups
Currently, the CommonViewer only has a constructor that takes a composite as input, whereas parent TreeViewer can take a Tree. Having a constructor taking a tree would allow a common viewer to be hooked on a filteredTree.
I assume the background of this request is to allow to use a filtered tree in the project explorer? That is definitely a very desired feature by lots of users, I know of.
(In reply to Lars Vogel from comment #1) > I assume the background of this request is to allow to use a filtered tree > in the project explorer? That is definitely a very desired feature by lots > of users, I know of. Yes, and also for outlines based on CNF (tern.java uses one, and the Eclipse/LSP integration is very likely to use it). The whole story of making it faster to add support for new languages can take advantage of CNF-based outlines.
ACtually, this proposal wouldn't help as the FilteredTree already builds a Viewer for the underlying tree, and we can't have multiple viewers (FilteredTree's one and CommonViewer) on the same tree. Let's rephrase what's wished.
I am "hijacking" this bug in the hope that my implementation satisfies the original requirement. At the last Eclipse Hackathon in Hamburg I talked to Lars about how cool it would be to have a quick filter mechanism for the Project Explorer (as he also expressed here in comment#1 and another user expressed interest for this in https://bugs.eclipse.org/bugs/show_bug.cgi?id=226046#c5). Lars proposed to make it work a bit like the M1+J (Incremental Find for Text Editors) feature. M1+J is currently not assigned in the Project Explorer. When pressing M1+J, a text field should appear in the status bar and get focus. The user can start typing and thereby set a filter pattern which filters the Project Explorer Tree. To quit, the user can press ESC when the filter text field has focus, or M1+ESC when the Project Explorer is active. This removes the filter text field and the tree filter. After my first implementation, I realized that this could be a feature applicable to all CommonNavigator views. So, I moved my efforts to the Common Navigator bundle. Gerrit patch follows. Please provide feedback.
New Gerrit change created: https://git.eclipse.org/r/93784
The current patch is very promising, doesn't introduce regression, doesn't introduce nor require new API. I'd like to merge it whenever it's bug free, hopefully for M7.
We currently in the process of moving Glance to e4 which will provide such a filter for all viewers. I suggest to move this bug to 4.8 and see if there is something missing in the Glance approach.
Sorry for the late reply (to your mail, not the previous comment :o)) I gave glance a try and the main difference between this patch and Glance is that Glance only searches the expanded nodes of a tree control. So, e.g., if you have all nodes collapsed in the project explorer, Glance would only search and highlight matches in Working Sets Names. This patch would iterate through all (collaped and expanded) nodes (trying to trade performance vs. functionality) and expand the matches. So in my opinion, both features have different use cases. Glance being the more universal (search and highlight wherever you are) and this patch being the deeper (search and filter, also collapsed items, only in common navigator views). -> +1 for merging this patch as well as integrating Glance
(In reply to Stefan Winkler from comment #8) > I gave glance a try and the main difference between this patch and Glance is > that Glance only searches the expanded nodes of a tree control. Maybe we could enhance Glance to support this? WDYT?
Might be possible. Not straight-forward, because Glance basically works on SWT level, not on JFace viewer level, but there is support to handle to SourceViewer and it might be possible to add support for the CommonViewer in a similar way...
I have the impression both approaches are complementary. A user story is for example a user looking for a file or a method in Project Explorer. In this case, it could be interesting to start by the quick search of Glance, looking only at already expanded element, that provides a very fast feedback. But those partial results wouldn't be enough for many use-cases. Then, with some progress monitor somewhere, the lookup could keep going on and do smarter things (like the one you implemented). That should cover most use-cases decently. Another thing with the resource-only implementation is that instead of using the Tree and viewer, it could reuse the "Open Resource" lookup mechanism which is actually pretty fast, and then from resolved resources, highlight the tree path in Project Explorer. I believe that would be faster. Also, if you plan to work on a lookup strategy that computes all nodes of the tree internally, don't forget to dispose the one that aren't used ASAP!
The original main user stories behind this bug for me were: a) in the project explorer when only working sets are open search for a project by (partial) name without opening all working sets b) locate a java package I had the time to try out the Glance incremental search today and for me - usecase a) is solved by Glance if in the Glance preferences the "enable auto index" feature is enabled (it is turned off by default) - usecase b) is solved by the search dialog (Find > Java Search > Package) So for me, the requirement to add an additional filter mechanism to the Project Explorer (or Common Navigator in general) is obsolete. So the question is: should we close this bug (and abandon the patch)? Or does anyone have additional requirements not covered by existing features (mentioned above or otherwise).
(In reply to Stefan Winkler from comment #12) > should we close this bug > [...] > does anyone have additional requirements not covered by existing features > (mentioned above or otherwise). I do. My main user-stories behind it, while I didn't clearly explicit it, is to automatically support search in any CNF based viewer/provider (see bug 508473). But it's quite an hard task IMO. The generic solution would be to let the various CNF content provider populate an index (just like the Glance one). The main challenge here would be memory cost if we let all providers participate in this index; so a way to restrict indexing to only some providers might be necessary. > (and abandon the patch) It's up to you ;)
Thanks for your quick reply ;-) (In reply to comment #13) > I do. My main user-stories behind it, while I didn't clearly explicit it, is to > automatically support search in any CNF based viewer/provider (see bug 508473). > But it's quite an hard task IMO. The generic solution would be to let the > various CNF content provider populate an index (just like the Glance one). The > main challenge here would be memory cost if we let all providers participate in > this index; so a way to restrict indexing to only some providers might be > necessary. So, would it help if I'd implement a Glance extension which makes it possible to let the CommonViewer customize its indexing? Or would you prefer a filter mechanism separate from Glance (i.e., based on what I already submitted to Gerrit)? And (independent of the decision whether to implement a filter or a Glance extension): Is it desirable to provide control about the indexing to the user (in a way similar to configuring Filtering... / Content Contributions)? Or should it be only configurable by the CNF Content Extension? (My current changeset provides CNF property keys to customize the filtering/indexing... )
Removing target milestone for all bugs that are not major or above.
> Removing target milestone for all bugs that are not major or above. Of course I meant "major or below". Sorry for the noise!
(In reply to Stefan Winkler from comment #14) > So, would it help if I'd implement a Glance extension which makes it > possible to let the CommonViewer customize its indexing? Or would you prefer > a filter mechanism separate from Glance (i.e., based on what I already > submitted to Gerrit)? The question is more: is this user story only about resources? If it's only about resources, then we already have Ctrl+Shift+R available to find resources. We could reuse its logic to build a "Resource Search" filter on Project Explorer and show matching resources in the tree. But do we need such complexity for CNF in general? I think in general, as CNF trees are lazy loading and CNF content provider can be long-running, they're not safe to crawl. > Is it desirable to provide control about the indexing to the user (in a way > similar to configuring Filtering... / Content Contributions)? > Or should it be only configurable by the CNF Content Extension? > (My current changeset provides CNF property keys to customize the > filtering/indexing... ) More or less same as above: shouldn't we just stick to Project Explorer and resources and see this as an alternative to Ctrl+Shift+R
Valid questions. Such a feature should not be on by default, since this would not suite for those cases where lazily filled trees with long-running fetch. Having this for the Project Explorer would be the most common use case. However, why then just providing it specific for this view? It adds some complexity, but also value. However, for the Project Explorer the performance issues would have to be addressed.
(In reply to Karsten Thoms from comment #18) > Having this for the Project Explorer would be the most common use case. > However, why then just providing it specific for this view? It adds some > complexity, but also value. I think the fundamental problem of finding 1 item in a potentially infinite lazily loaded tree is in the general case not solvable. That's why I suggest that we don't try to find a generic solution for the CNF, and instead stick to finding specific elements (in another way that's specific to the kind of elements) and then to show them in the tree.
Created attachment 284334 [details] Mylyn filtering (In reply to Mickael Istria from comment #19) > > I think the fundamental problem of finding 1 item in a potentially infinite > lazily loaded tree is in the general case not solvable. I agree (try pressing numeric * on a project, it locks up Eclipse for quite some time. (numeric * is the windows "expand all" shortcut Linux must have something simmilar)). I want to point out two other related things in the IDE currently used. One is the "Link with editor" action. Even when Eclipse is restarted with a collapsed tree, the navigator shows an item in the tree when the editor gets focus. Another one (short movie attached) is what Mylyn does. It is able to operate on the tree from the outside in some way to only expose the items that are in the current task context.
As discussed, this cannot be fixed in the general case of CNF for performance reasons. Such a quick filter text area on Project Explorer would still be welcome (it would basically be more or less an alternative way to handle "Open Resource" on-site, without a dialog); but it can't rely on CNF, it would have to first use resource API, like the dialog does, and then build a CNF filter out of it to only show the matching items (and maybe style their labels).
