Community
Participate
Working Groups
I find myself often using the heirarchy view to find classes when developing my plugins, and it would save a lot of time and reduce my cognitive load with using the hierarchy if I could filter the classes it shows (similar to what's available for the package explorer). In particular, When I want to find an appropriate dialog boxes, I open th e hierarchy for the Dialog class and get a whole bunch of subclasses. The ones I'm really interested in are the public API ones, so I want to filter out the non-public classes and the classes that match the glob "org.eclipse.*.internal.*".
(here's to hoping that this isn't already in 3.0, since I have yet to try that series out yet)
Martin, it should be easy to do using - WorkingSetFilterActionGroup - CustomFilterActionGroup
Dani: The problem are that you can't just filter. It's a tree and some elements would be filtered but have to stay in the tree as there are children to be shown (the solution will be to use a special image for such 'support' nodes. The feature is on the plan, but probably for M5 or M6
Agree. we had to solve the same problems for the hierarchical layout used in the Package Explorer and Packages view. We implemented something on-top of the existing filters to be able to use the custom filters there as well. This might fit your case as well.
and i'd like to be able to filter out types that are not public (for example) my usecase: i open type hierarhcy of java.lang - i see lots of types that are useless for me because i can't access them anyway. i'd like to see only the public types
The "What's new in M6" told me to comment on this bugzilla about filters for the code assist, quick fix, (and open type maybe?). perhaps that was a typo. Anyway, for this type of filtering, I'd like to be able to specify Types to exclude completely, like sun*/javax*, but I'd also like to be able to specify types to show a warning about, like *internal*, rather than completely hide them from code assist and other functions. Perhaps show the type, but use gray text or modified icon. It sounds like a great new feature! Let me know if there is a dedicated bugzilla for this feature.
Randy, please file a new bug report for that idea. The type filter introduced in M6 is not (yet) used by the type hierarchy.
Is there a well-defined extension point to this feature? I am developing a plugin that employs such filtering as well. So it would be great to have ane xtension point that a) gives access to the filters as Strings and probably even b) filters a list of resources automatically, based on the filters set. Even better would be if somebody could plug in an additional tab (say for my plugin) to specify custom filters for each feature. Each tab should have the equivalent functionality to the one provided in M6. This could also solve the enquiry Randy had.
I guess you're referring to the type filters. This bug report is not the right place for it. Please open a new feature request for this.
*** Bug 59281 has been marked as a duplicate of this bug. ***
When implementing the filters, please note that the duplicate bug 59281 is requesting a filter for inner classes, particularly anonymous ones. Would be nice if you could distinguish between "private classes" and "inner classes" in the filters.
Martin, is this on the plate for 3.1? I'd love to see this. I was just browing the OutputStream hierarchy yesterday and it's unbelievable what you see in there. I just wanted to see accessible stuff from java.io. The rest is was just noise but there was no way to tell.
I'm hoping to find time for that. The general filter infrastructure is pushed down to platform and I'm waiting for that because what we currently have doesn't work for the hierarchy (CustomFiltersActionGroup)
*** Bug 175269 has been marked as a duplicate of this bug. ***
Are there any updates on this? I must say it would be very nice to filter out all the sun or non-public classes when learning an API.
>Are there any updates on this? No (as you can see in the bug).
Actually, I just opened the hierarchy view on org.eclipse.swt (the project) and I was initially annoyed by all of the non-swt and non-api classes cluttering up the view, but then I used "Select Working Set..." on the Hierarchy View menu to define a Java working set that only included the packages I cared about, and then I played around with "Edit Active Working Set..." to fine tune the working set. Luckily for me <g> swt is set up so that if a package is not api, it has ".internal" in its name, and this made my task quite easy. I was also able to ignore all of the JRE System Library jars, because I don't need to see anything in those. This turned out to be (for me) a very good solution, and the only annoyance I was left with was lots of visible anonymous inner classes, and for this I opened bug 272333. Adam and Michael, I don't know if this would help for your cases, but please give it a try. Note that you have to create a "Java" working set, and drill down to at least the package level, before you get the real benefits of the filtering.
