This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
For cases like navigator filtering is better than search. When user types "add" only methods having add in name should be shown the rest should be filtered out. I would prefer filtering also in files view and others.
OK, but what do you want from openide.explorer? Can you provide a patch? Otherwise I expect you own your explorer view component as well as your hierarchy of nodes, then: 1. Filtering of the hierarchy can be done with FilterNodes. 2. Listening on keys typed inside BeanTreeView subclass shall be possible too by removing existing key listeners from your JTree and adding yours. As a result there is nothing to be done in openide.explorer, as far as I can see.
If this is how it should be implemented, why there is a common "impl" for search in the openide.explorer? Everyone can implement it himself. But each impl will be a copy of some previous generation of the code. The same holds for filtering. From my point of view filtering is the same as searching (it's only different form of presentation to user) and should be solved in the single place (openide.explorer).
Created attachment 96793 [details] protected TreeView.doSearch method
I fully understand that you don't want to implement the search UI yourself. In such case I suggest to expose "doSearch" method to subclasses, which you could easily reimplement. As far as I can tell this is compatible refactoring, all the existing tests are passing OK. I, however don't know if this satisfies all your needs. That needs to be tested. Implement bug 177081 and if things are fine, feel free to pass API review with the "doSearch" change.
Unless you can use the new doSearch method successfully for your usecase, there is no need to do this API change.