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.
In 4.1, I was able to expand build.xml, select a node, create menu items or toolbar buttons or shortcut keys for the Ant script. However, in 5.0 builds I am not able to expand build.xml like this. I think this was a really cool feature in 4.1 and I hope this is not gone in 5.0...
Sorry. I see them now... thanks to Jan Lahoda... in the Navigator window... (Displayed by default, otherwise Ctrl-7.)
Reopening, because if Navigator isn't open, user will never know about this re-implementation of target display. But making it P3.
I would bet that there will be a lot of complains about this removed feature. I think we will need increase it back to P2 in close future.
Well, I think the only problem is that the Navigator does not appear when you double-click build.xml. For the rest, I think it's an improvement.
Navigator is open by default in the IDE. If the user closes it, that's their problem I guess. It would not be correct to open the Navigator when a build script is opened; would be very annoying in many cases, and would be inconsistent with behavior of Java source files.
Seems that this really is a fundamental question of: - What determines what appears in the navigator, and what appears in the project tree view(s) For instance, Java classes can be expanded down to the methods, fields, constructors, etc. While, properties files can also be expanded down to element detail. So, why should the drilldown be removed for ant build files? It seems inconsistent and either one of the following should happen: - Give the user an option to use the Navigator window - Duplicate the functionality (to a reasonable extent, and in a consistent fashion) of the navigator in the tree view. I'm re-opening, as I can see this as a potential serious problem for new users who aren't familiar with the difference. At the very least, a clear definition of "Navigator Window", and what does and doesn't go there seems appropriate. User friendly-ness is HUGE in my book. Also, the statement: "...would be inconsistent with behavior of Java source files.." The mere fact that I can drill down to a pretty granular degree in the project treeview for java source files makes the current implemenation quite inconsisent. If it was consistent, this bug would have never been filed.
Re. *.properties: these *will* have navigator views at some point (and the Explorer subtree can be removed). The owner of this module has not gotten to it yet, unfortunately. (There are many, many other things which inconsistent and buggy about *.properties files but to date this has not been a priority for that team.) Re. *.java: I believe there are some operations which are still available on *.java subnodes which are not available in the Navigator view, e.g. copy-and-paste, though I am not sure. Ultimately the intent is to remove the *.java subnodes but it might not be possible just yet.
Adding Jano on CC to hear his opinion.
We (HIEs, others) were discussing an option to remove child nodes from files in project explorer, but I don't think there was any decision made yet. It's very likely that we'll do it for all files, but I'm not sure about it yet. I personally think that if we decide to remove those nodes, we should do it for as much files as possible at once (meaning in the same release). I tend to say that we should revert the build.xml subnodes back. Removing those nodes from build.xml won't really help in usability overall and it introduces inconsistency. Also removing subnodes from Java files won't be that easy as we need to implement the java navigator improvement. OTOH, the build.xml files are not that highly visible (they don't show up in project window for standard projects), so maybe we can live with this exception for one release. Ccing Jindra who designed navigator for his opinion. Reopening till the decision is made about this issue.
OK, up to you. Probably not much work to readd the build.xml subnodes (not sure offhand). Definitely not for beta.
Still awaiting UI decision.
*** Issue 65409 has been marked as a duplicate of this issue. ***
Jano, Jindra, please we are waiting for your decision. The isse was also reported by NetCAT participant(s).
I definitely agree with Jano's comments. IMO we should revert the build.xml subnodes back even this file is not so visible.
Please revert this. The Navigator window takes up much space and when it is open it is hard to know which build.xml you are running if you happen to have more than one file with that name per project or if several projects are open since you cannot see its parent directory/project.
Re. "it is hard to know which build.xml you are running if you happen to have more than one file with that name per project" - that I can and will fix separately, for the case that the build.xml is open in the Editor. Will display e.g. "Navigator - build.xml [My Project]" if build.xml contains <project name="My Project" ...>
Main fix: committed * Up-To-Date 1.2 ant/src/org/apache/tools/ant/module/nodes/AntNavigatorPanel.java committed * Up-To-Date 1.40 ant/src/org/apache/tools/ant/module/nodes/AntProjectNode.java Improve Navigator title when build.xml selected in editor: committed Up-To-Date 1.7 ant/src/org/apache/tools/ant/module/loader/AntProjectDataEditor.java
*** Issue 68168 has been marked as a duplicate of this issue. ***
It seems much of this issue in general is assuming users do not use the different utilities provided by the Nodes. What usability studies were devoted to these ideas? What affect does removing all these things have? BeanInfo editor is one example. What about the Nodes for ANT scripts where users can see the targets then double click and jump to them. There is A LOT of functionality that simply removing the Nodes takes away immediately. It seems a more prudent method would be to first find out what features users are using, find good workarounds for them if it is deemed better to removed the Nodes after careful consideration and user contact, then go from there. Truthfully this seems very on the whim.
Has anyone noticed this same issue has removed layer.xml editing? This is affecting a lot of functionality. I'm not sure exactly how it can be marked as fixed as it has broken many other areas. What are the plans for all the missing functionality? Some of this is very bad, and will kill developer efficiencies the IDE has provided. I would much rather not have the new editor changes etc and get back what we have lost here. I'm willing to bet I'm not alone by a long shot.
Removing subnodes for Ant scripts has no effect on available functionality; all the same things are available from the Navigator window (as well as in other ways, e.g. context menu in the editor). I take no position on whether the same nodes should additionally be present underneath the file node, except that the style used for Ant should match that used for Java sources. Please use nbui@netbeans.org for general UI discussions. Removal of structural editing functionality for Ant happened long before subnodes were hidden; that was done due to persistent and unsolvable problems with corruption of build scripts due to lack of a general and well-tested API for structural editing of XML files. (Which continues to this day as far as I know, though perhaps xml/xdm is finally up to the task.) In any event code completion in Ant scripts takes up some of the slack (it could be greatly expanded if I had any time to do so); I have no plans to reintroduce structure editing.