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.
Problem is described in http://openide.netbeans.org/openide-dev/msg00512.html, it is not easy to select nodes in explorer, because the explorer requires that selected nodes would be children of the root (which can be in common cases some FilterNode). Suggested fix: Create org.openide.explorer.ExplorerLocator with one method Node[] locate (Node[] arr). Btw. probably has to be Serializable. Add new construtor to ExplorerManager that will take the instance of ExplorerLocator and consult its method each time someone tries to set a node that is not under root (normaly would generate InvalidArgumentException) Create package private implementation of the locator. At least one ExplorerLocator.DATA_OBJECT that would locate the right node based on the hierarchy of data objects and maybe also ExplorerLocator.FILTER or NAME that would somehow map nodes based on the same hierarchy of names. The names suggested in this bug report can be subject of change.
Automated change of version from Other to Dev.
It is really a good enhasncement, as in most of the cases, it is required to highlight a child node, depending on the action performed by the user.
This would be great. It would be also be good if common Explorer operations, such as this, could be performed without the programmer having to understand so much about the internals of explorer and its nodes (for example, I'd rather not have to know about filternodes or that nodes may be cloned). It would save programmers a lot of time if we could manipulate an Explorer while only knowing about types Node and DataObject and that Nodes have children and a parent and that the Explorer has a RootNode; also, from the DataObject I can get the Node, and vice-versa. It seems like I shouldn't need to know much more than this in order to make good use of an Explorer.
Target milestone -> 3.3
Target milestone -> 3.3.1.
I think we will need similar locator interface for Looks, if we want to solve #6559. Are there any plans on that ?
Enh looks reasonably, however I can't estimate needed amount of work, as I still don't know much about explorer internals. Anyway, Jiri, let Yarda and Svata help you. Don't forget that's needed also to write tests.
This issue looks hard to implement it demands a lot of time (no time enough :-). Issue has not any impact on end-user we (as core-ui team) should be focused on end-user impact first. Do you think it is acceptable to postpone to 4.0? Comments are welcome.
Well :-) since users are asking for such features from 3.1, I think, we can offer at least limited solution to them.
I think it definitely has an impact on the end-user; read nbusers, people ask for editor <-> explorer synchronization every week. Other products do it and people expect it to be there. The issue also affects module developers, who routinely ask on dev@openide how to do this and are told "you can't"; and code stability, as there are several half-broken implementations scattered throughout the code base (main explorer after template creation; search window; etc.) which work in most but not all cases and need to be maintained as bits of implementation change. It may take some time to implement, I haven't tried to estimate it.
I've heard that UI team is preparing a redesing of editor/explorer relationship. Something like opening editor together with a "structured view". We know that it is hard to fix this issue in current architecture, but it is easier to navigate in small "structured view" than in whole explorer (with looks). I would suggest you to ask the UI to find out what they want and negotiate some implementable compromise.
True, synching with a limited structure view would be somewhat easier, though of course that in itself is a big API/UI change. I think we would still want to be able to select arbitrary nodes in the Explorer, but it would be lower priority.
Please also see Issue #20486
*** Issue 20486 has been marked as a duplicate of this issue. ***
Has been implemented as part of issue 18856. *** This issue has been marked as a duplicate of 18856 ***
I don't believe this is a duplicate of issue #18856. This issue is about providing an API to select nodes of known contents programmatically. #18856 does it using a (hopefully temporary) hack just for the case that you are editing a file. Other issues such as issue #22308 still need the API. Also #18856 *should* be using a proper API because otherwise code in the editor module will have to be rewritten every time the Explorer structure changes - for example, if there is a real Projects tab, especially with a logical view. Therefore I propose to reopen this issue, make it P3/TBD, and make it block #18856.
Seems to me that we are able to select the right now if we know the structure under them. FileSystem view can easily locate Node belonging to a DataObject and that is no hack, its just because it knows the structure behind the nodes. Projects View can locate node in its tab, again because it knows the structure. The same applies to Versioning Explorer, etc. Every view that knows its structure, can select any of its nodes and does not need any API for that. So maybe this is not duplicte, but wontfix. As concern issue #22308 the org.openide.actions.NewAction already selects newly created nodes, but only if they are directly under the node where NewAction has been invoked. This was considered sufficient, but can be extended to any finite depth. On and on, I believe the we do not need any better general API for selection than ExplorerManager.setSelectedNodes. That is the reason why I closed the issue.
Yes, a *view* can select a node in *itself*. This API request is for *arbitrary code* to be able to select a node in some view whose precise structure it should not be aware of (e.g. a logical view in a projects tab). Or the caller may know the exact node tree (perhaps modulo FilterNode's), but not the ExplorerManager displaying it - as in the case of NewTemplateAction, which still is only able to select a node by virtue of a hack in NbMainExplorer. (Also New/PasteAction only are able to select anything by using the global TopComponent.Registry, it seems. Maybe that could be fixed independently.) So I do not agree with this issue being closed (either as DUPLICATE or WONTFIX), I still think it should remain open.
Reopening. There are actions which select nodes by origin, but these must always be collocated with the code that creates the view. Still desirable to be able to select nodes without having direct access to the code that creates the view.
Reassigning to new module owner Tomas Holy.
Would be useful for issue #152711, for example. For now, have to define an SPI between autoproject.core and autoproject.java just to call PackageView.findPath.
Created attachment 86265 [details] Sketch of API
I am playing with an API for this that I believe would allow for code simplification and consolidation. Need to further study the use cases and develop the patch to be sure.
*** Bug 102465 has been marked as a duplicate of this bug. ***
Time to give up, finally?
org.netbeans.spi.project.ui.PathFinder partially accomplishes this, though limited to the project system.