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.
Write a spec.
Set target milestone to TBD
I guess this means for an outline view of the selected file (or just open file?), as many IDEs have. Such a view would be a TopComponent that we could decide to display by default (or not). The spec should probably take existing IDEs as a starting point; typically their equivalent of the Explorer does not show file substructure as NB's does, but when you open a file in the editor (text or otherwise), you see a tree-structured view of its contents (e.g. Java methods and so on). Simple impl idea with minimal impact on existing modules: have some optional but documented attr on nodes to mark them as being the end of what you should see in the Explorer but the start of what the Outline component should show. E.g.: public MyNode() { super(new MyChildren(...)); Node.putValue("outlineRoot", Boolean.TRUE); } The BeanTreeView used in the Filesystems & Project tabs of the Explorer would look for this attr and not show children of any node with it. The Outline component would listen to the selected node, if it is in an editor window, and if it has the attribute, display a tree view rooted at the node. DataNode would automatically set this flag, covering most of the use cases. Issues: - requires a patch to some Explorer code, so cannot be done as a pure module (except by creating alternate demo Explorer tabs with the specified behavior); the Outline component itself could be in a module however - exact meaning of "open in the editor" is a little fuzzy in current NB APIs, since listening for CloneableEditorSupport cookie is too narrow (excludes graphical editors); could e.g. listen for the active top component and check if it is docked into CES.EDITOR_MODE and has one activated node with the right attr, but this is somewhat hacky - another trick might be to define some OutlineCookie (produces a root Node) to be found in the TopComponent.lookup of any suitable editor component (in any docking mode); CloneableEditor could then add this automatically if its activated node is not a leaf (TBD: deal with fact that Java editor changes activated node acc. to cursor position), or CloneableOpenSupport could do this in openCloneableTopComponent for any kind of editor. Tim I know you have some kind of outline-like component. While it sounds cool, it is probably too fancy for these purposes; certainly using Looks and so on is out of the question for the current code base. Do you have any very simple such component that just works with unmodified Java element nodes as well as with whatever other data node substructure might be around (e.g. Ant script subnodes), and requires no experimental libraries or window system hacks? If not, one could be written along the lines given above, for evaluation purposes.
Earlier revisions of the outline panel will do this. At the same time, the implementation I'm working on now on my own time will fulfil all the needs of any outline-type component. You can try a draft version as follows: - Check out workspaceswitcher - Run ant outline_jars - Install it There's a partially refactored version in workspaceswitcher/navigator, but I just started refactoring it and it's not yet compilable. It splits the outline component and a module which provides Looks for Java (class members and inherited methods, selectable by a combo box - the same stuff in the current version). I would enjoy being able to do some official work on this rather than saving it for weekends and evenings. The current version depends on - Looks - Registry (this dependency can be eliminated) - HTML rendering (it has its own copy of this until it appears in the trunk) Please try it - I can't live without it now (which is why I've written and maintained it for the last year and a half). The question is, how close are we to integrating Looks for real? When I converted to use them, it seemed very close, but it doesn't seem to be getting closer. We could revert to an earlier version of the outline panel and use that - but if we'll have a real Looks release by, say, September, I think we should stick with the current direction and get that solid. There are considerable advantages to staying with directly rendering a Look - mostly relating to performance and potential deadlocks. The alternative is writing/maintaining something we know we will throw away.
Isn't this addressed by Navigator in NB 4.1? I'd say it is for Java objects. Future versions of Navigator should allow for plugging in outline view support for other types of objects.
Stando, could you please evaluate?
implemented in spi.navigator - closing (not sure which milestone to set though)