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 63634 - [50cat] Project view vs. Navigator inconsistent for certain objects (namely build.xml)
Summary: [50cat] Project view vs. Navigator inconsistent for certain objects (namely b...
Alias: None
Product: projects
Classification: Unclassified
Component: Ant (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
: 65409 68168 (view as bug list)
Depends on:
Blocks: 88163
  Show dependency tree
Reported: 2005-09-05 10:54 UTC by Geertjan Wielenga
Modified: 2007-05-05 14:26 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Geertjan Wielenga 2005-09-05 10:54:57 UTC
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...
Comment 1 Geertjan Wielenga 2005-09-05 11:14:00 UTC
Sorry. I see them now... thanks to Jan Lahoda... in the Navigator window...
(Displayed by default, otherwise Ctrl-7.)
Comment 2 Geertjan Wielenga 2005-09-09 07:29:27 UTC
Reopening, because if Navigator isn't open, user will never know about this
re-implementation of target display. But making it P3.
Comment 3 zikmund 2005-09-09 11:28:37 UTC
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.
Comment 4 Geertjan Wielenga 2005-09-09 11:38:46 UTC
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.
Comment 5 Jesse Glick 2005-09-09 18:32:09 UTC
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.
Comment 6 clever 2005-09-15 16:50:40 UTC
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.
Comment 7 Jesse Glick 2005-09-15 18:34:24 UTC
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

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.
Comment 8 zikmund 2005-09-16 09:13:50 UTC
Adding Jano on CC to hear his opinion.
Comment 9 jrojcek 2005-09-21 14:57:33 UTC
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.
Comment 10 Jesse Glick 2005-09-21 23:12:38 UTC
OK, up to you. Probably not much work to readd the build.xml subnodes (not sure
offhand). Definitely not for beta.
Comment 11 Jesse Glick 2005-09-30 02:14:43 UTC
Still awaiting UI decision.
Comment 12 Jesse Glick 2005-09-30 02:16:03 UTC
*** Issue 65409 has been marked as a duplicate of this issue. ***
Comment 13 Marian Mirilovic 2005-09-30 08:10:53 UTC
Jano, Jindra,
please we are waiting for your decision.

The isse was also reported by NetCAT participant(s).
Comment 14 Jindrich Dinga 2005-09-30 09:44:14 UTC
I definitely agree with Jano's comments. IMO we should revert the build.xml subnodes back even this 
file is not so visible.
Comment 15 misterm 2005-09-30 15:57:55 UTC
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.
Comment 16 Jesse Glick 2005-10-03 23:34:35 UTC
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" ...>
Comment 17 Jesse Glick 2005-10-04 06:41:12 UTC
Main fix:

committed   * Up-To-Date  1.2        
committed   * Up-To-Date  1.40       

Improve Navigator title when build.xml selected in editor:

committed     Up-To-Date  1.7        
Comment 18 Jesse Glick 2005-11-15 00:44:54 UTC
*** Issue 68168 has been marked as a duplicate of this issue. ***
Comment 19 _ wadechandler 2007-05-05 03:30:17 UTC
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.
Comment 20 _ wadechandler 2007-05-05 04:02:58 UTC
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
Comment 21 Jesse Glick 2007-05-05 14:26:01 UTC
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 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