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.

Bug 7551 - Enhance ExplorerManager's ability to select some nodes
Summary: Enhance ExplorerManager's ability to select some nodes
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Nodes (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker with 1 vote (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: API
: 20486 102465 (view as bug list)
Depends on:
Blocks: 6559 18308 20643 22308 26326 26525 27444 28685 29760 46254 68500 152711 215297
  Show dependency tree
 
Reported: 2000-09-01 09:51 UTC by Jaroslav Tulach
Modified: 2012-07-27 14:41 UTC (History)
15 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Sketch of API (6.96 KB, patch)
2009-08-14 21:12 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2000-09-01 09:51:43 UTC
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.
Comment 1 Jan Zajicek 2001-01-23 09:32:59 UTC
Automated change of version from Other to Dev.
Comment 2 prakasha.aradhya 2001-04-19 16:45:39 UTC
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.
Comment 3 eakle 2001-04-24 00:34:00 UTC
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.
Comment 4 Jan Chalupa 2001-05-06 08:11:00 UTC
Target milestone -> 3.3
Comment 5 Jan Chalupa 2001-11-27 13:02:31 UTC
Target milestone -> 3.3.1.
Comment 6 Svata Dedic 2002-02-05 07:35:27 UTC
I think we will need similar locator interface for Looks, if we want
to solve #6559. Are there any plans on that ?
Comment 7 David Simonek 2002-02-05 15:00:11 UTC
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.
Comment 8 Jiri Rechtacek 2002-02-08 10:35:37 UTC
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.
Comment 9 Svata Dedic 2002-02-08 11:21:46 UTC
Well :-) since users are asking for such features from 3.1, I think,
we can offer at least limited solution to them.
Comment 10 Jesse Glick 2002-02-08 12:19:07 UTC
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.
Comment 11 Jaroslav Tulach 2002-02-08 12:44:33 UTC
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.
 
Comment 12 Jesse Glick 2002-02-08 13:33:09 UTC
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.
Comment 13 Melih Ovadya 2002-02-13 20:36:18 UTC
Please also see Issue #20486
Comment 14 Jiri Rechtacek 2002-02-14 09:33:52 UTC
*** Issue 20486 has been marked as a duplicate of this issue. ***
Comment 15 Jaroslav Tulach 2003-12-03 10:24:10 UTC
Has been implemented as part of issue 18856.

*** This issue has been marked as a duplicate of 18856 ***
Comment 16 Jesse Glick 2003-12-03 15:27:10 UTC
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.
Comment 17 Jaroslav Tulach 2003-12-04 14:08:02 UTC
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.
Comment 18 Jesse Glick 2003-12-04 15:02:25 UTC
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.
Comment 19 Jesse Glick 2004-08-04 18:12:10 UTC
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.
Comment 20 Antonin Nebuzelsky 2008-02-07 16:12:10 UTC
Reassigning to new module owner Tomas Holy.
Comment 21 Jesse Glick 2009-07-01 01:35:35 UTC
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.
Comment 22 Jesse Glick 2009-08-14 21:12:18 UTC
Created attachment 86265 [details]
Sketch of API
Comment 23 Jesse Glick 2009-08-14 21:13:43 UTC
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.
Comment 24 Jesse Glick 2010-05-04 23:04:23 UTC
*** Bug 102465 has been marked as a duplicate of this bug. ***
Comment 25 Jaroslav Tulach 2012-06-20 14:24:02 UTC
Time to give up, finally?
Comment 26 Jesse Glick 2012-07-27 14:41:36 UTC
org.netbeans.spi.project.ui.PathFinder partially accomplishes this, though limited to the project system.