Community
Participate
Working Groups
In a project with a lot of files, it would be nice to be able to have a text box in the Package Explorer that automatically filters and fills the list with matching files. Like the "type filter text" in the Preferences window. It's much quicker than having to define multiple Working Sets or drill down the tree until you find the file you want.
We are planing to experiment with that in 3.3
*** Bug 151638 has been marked as a duplicate of this bug. ***
*** Bug 204036 has been marked as a duplicate of this bug. ***
*** Bug 210573 has been marked as a duplicate of this bug. ***
bug 69200 is the corresponding request for the navigator. See bug 69200 comment 7 why this request is non-trivial.
*** Bug 218316 has been marked as a duplicate of this bug. ***
I'd like to reiterate on this issue. So, we need a quickfilter in Package Explorer and/or Navigator views. I think there is an approach that may work in those views without hurting performance or memory. If you think of such filter as search, then there is already backend that is capable of running such searches that is used in "Open Type" and "Open Resouce" dialogs. Now Package Explorer view just need to flip input to the search results.
*** Bug 264370 has been marked as a duplicate of this bug. ***
Also see bug 34705.
Created attachment 166368 [details] UI mock-up. UI mock-up from bug 34705.
*** Bug 386309 has been marked as a duplicate of this bug. ***
I put the search box in the content of the view, see here: https://github.com/vogella/jdt-package-explorer or use this update site to try it: http://www.vogella.com/updatesite/jdt Is this an option or is it required to go into the view header? I personally like both approaches, putting it in the view header makes it a bit crowded IMHO but saves space for the content.
(In reply to comment #12) > I put the search box in the content of the view, see here: > https://github.com/vogella/jdt-package-explorer or use this update site to > try it: http://www.vogella.com/updatesite/jdt > > Is this an option or is it required to go into the view header? I personally > like both approaches, putting it in the view header makes it a bit crowded > IMHO but saves space for the content. Could you attach some screenshots?
The UI is not the main blocker here. The main problems are: - filter behavior (does it only consider visible elements or all possible children at all levels?; cf. bug 69200 comment 17) - filtering performance (bug 69200 comment 7) - efficiency and correctness when model changes must be reflected in the view Lars, how does your proposal deal with these issues? I don't have time to decipher whitespace changes in https://github.com/vogella/jdt-package-explorer/commit/97a8c0d31938112a6d39e3a7cada8538590f3b58
Created attachment 219703 [details] Screenshot @Dani: Screenshot attached
@Markus: If desired I can redo the change without whitespace changes, sorry for that I assumed JDT would use the default Eclipse formatter. To your questions: 1.) I only filter on project names, e.g. the top node. This way I have a "dynamic project name based working set" like behavior. 2.) The check does not add any runtime complexity in the O notation as it is a fixed set of instructions and is included in the content provider. private boolean matchesFilter(Object project) { if (project instanceof IProject) { IProject p= (IProject) project; String name= getProjectName(p); return pattern.matches(name); } if (project instanceof IJavaElement) { IJavaElement p = (IJavaElement) project; return pattern.matches(p.getElementName()); } // Should never be called return true; } 3.) Check is included in the PackageExplorerContentProvider, so everything which refreshes the content provider will also refresh the filter. Let me know if I should create a whitespace free solution. If I make the change I plan also to use a ViewerFilter directly.
The comment // Should never be called is incorrect. Will return true for all other elements than IProject and IJavaElement
See bug 69200 for a more general approach.
@Dani: IMHO Bug 69200 is a different feature request. It is an improved find feature while this Bug is about a dynamic filter for the tree.
(In reply to comment #19) > @Dani: IMHO Bug 69200 is a different feature request. It is an improved find > feature while this Bug is about a dynamic filter for the tree. Well, it's somehow connected. If there's a generic way to search, then you can also filter, which is probably what bug 69200 would implement anyway.
(In reply to comment #20) > (In reply to comment #19) > > @Dani: IMHO Bug 69200 is a different feature request. It is an improved find > > feature while this Bug is about a dynamic filter for the tree. > > Well, it's somehow connected. If there's a generic way to search, then you > can also filter, which is probably what bug 69200 would implement anyway. That's probably true, but look at the age of that bug; is it realistic that it will actually be implemented in the foreseeable future (ie, the next release or two)? Given the infrastructure nature and open questions around it, I'm skeptical. Here, however, we have a much smaller scope feature that *has a working patch*. IMO it is foolish to reject it just because there's a discussion (not plan, no code) about a more generic solution out there. I can tell you from hard-earned experience that the lack of this feature really hurts Eclipse for very large workspaces.
*** Bug 417401 has been marked as a duplicate of this bug. ***
(In reply to Markus Keller 'away till 2013-09-22' from comment #14) > Lars, how does your proposal deal with these issues? I don't have time to > decipher whitespace changes in > https://github.com/vogella/jdt-package-explorer/commit/ > 97a8c0d31938112a6d39e3a7cada8538590f3b58 Shall I create a Gerrit review for this change?
(In reply to Lars Vogel from comment #23) > (In reply to Markus Keller 'away till 2013-09-22' from comment #14) > > Lars, how does your proposal deal with these issues? I don't have time to > > decipher whitespace changes in > > https://github.com/vogella/jdt-package-explorer/commit/ > > 97a8c0d31938112a6d39e3a7cada8538590f3b58 > > Shall I create a Gerrit review for this change? I prefer a more general solution (see bug bug 69200) and at the moment we are too busy with Java 8 to spend time for changes like this one.
(In reply to Dani Megert from comment #24) > (In reply to Lars Vogel from comment #23) > > (In reply to Markus Keller 'away till 2013-09-22' from comment #14) > > > Lars, how does your proposal deal with these issues? I don't have time to > > > decipher whitespace changes in > > > https://github.com/vogella/jdt-package-explorer/commit/ > > > 97a8c0d31938112a6d39e3a7cada8538590f3b58 > > > > Shall I create a Gerrit review for this change? > > I prefer a more general solution (see bug bug 69200) and at the moment we > are too busy with Java 8 to spend time for changes like this one. Sad response. See Comment 21 above.
I agree with Eric ("I can tell you from hard-earned experience that the lack of this feature really hurts Eclipse for very large workspaces."). I tried the solution proposed by Lars and find it very good. Maybe there could be an action (http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fworkbench_basicext_viewActions.htm) with a 'filter' icon, to activate this textbox, disabled by default. In this way users are: 1) not alarmed by this new thing 2) lightly invited to this new thing :) but this is not very important in the end. Instead having this feature is very important IMHO.
