Decision to remove sub-nodes from many file types in the explorer view

There was a recent decision to attempt to make the
explorer node view and navigator more consistent.  It
was apparently determined, behind closed doors and
without user interaction, that removing the Nodes from
the explorer view was the best option.  Had user
interaction with this decision been taken developers
would have learned:
*) People use the layer.xml editor for module
development.  It is probably in the new book on RCP
development.  It is now missing as the sub-nodes have
been removed, and no comparable feature has yet to be
added back.

*) JavaBeans are used in many technologies.  The
BeanInfo editor is used by many IDE users.  It is
integral to UI component library development.  As the
Node is missing for Java files it is no longer
avaiable.

I'm sure there are others, but these are my biggest
gripes.

UI specifications should not be an overriding and
hindering concept.  If functionality is used and is
crucial to a concept such as BeanInfo and JavaBeans
then it should be reviewed better and not just
removed.  It should be included in a different way or
be left alone, but this should happen only after
careful analysis and review not on a whim.  The new
way of doing something should be available before
removing the old way, it should be reviewed, and user
acceptance and testing be given a chance.

I see this from time to time in NetBeans, and frankly
this doesn't make any sense.  I understand a UI
specification needs to be created as it helps with
multiple things, but anything can be followed too
strictly.  The same can be said for situations I have
seen where different developers say we don't have any
good use cases.  Sometimes thinking outside the box is
more beneficial to the project and the community.

Reviewing further, this presents a far worse usability
problem.  In the case of the BeanInfo editor, if a
NavigatorPanel is the "new" way of getting it into the
IDE,  the way Navigator currently works, I browse off
a file and then back to it then it reverts back to its
default state with the first navigator panel being
selected and not the one I want to work with.  

In NB 5.5 I would have 2 or 3 beans I'm working on and
I could have their "Bean Pattern" nodes expanded and
be working on all of them and not lose valuable time
just switching between them.  Now, were the Navigator
to be used and it is not modified from its current
usability one would have to constantly change from
Bean to Bean, select the appropriate panel from a
combo-box, then start working on bean patterns.  I
really don't see how we can get the same support from
a UI element such as the navigator which has to be
reset every time an element or file is selected.

This same thing would be true if the "Bean Pattern"
node is moved to a dialog tool of some sort as a
context menu item on Java files.  I really do not see
the gains in this "fix" for consistency in the UI
specification in regard to all files.  Who made this
determination and based on what?  

I'm sorry for getting a little flustered, but this is
really irritating as there is no apparent good
solution moving forward for all this missing stuff,
and there really doesn't appear to have been given a
fair amount of thought and study to this issue before
proceeding forward.  It seems for the BeanInfo editor
the best solution is to bring back the Node for the
.java files for the BeanInfo editor, I'm sure there
are others modules this is going to affect as well.

There is an old saying "If it ain't broke don't fix
it."  It falls in line with the KISS principle.  OK,
so the navigator had some inconsistencies with the
file
nodes in the explorer view.  From the look of things
the Navigator needed more changing or minimizing and
the explorer nodes needed to be kept with regard to
certain file types and concepts, or the Navigator
needed to replicate what it needed to do it's job of
being a navigator, but the main issue is the way the
navigator works doesn't meld well with the Nodes view
of allowing users to work on multiple Nodes of
multiple
files at the same time by keeping certain work session
elements static as the explorer tree view does.  It
just isn't as efficient for the developer.

I use the IDE every day.  This issue has affected me
in many many ways.  I felt its impact immediately in
different areas.  I thought the missing stuff was just
not back yet as part of the Java model overhaul, but
now that I see this is part of a UI change, I have to
say something.  It is certainly affecting my day to
day working, and it is making my work in the IDE much
less efficient.

Wade


==================
Wade Chandler
Software Engineer and Developer

Netbeans Community and Dream Team Member:
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam

Check out Netbeans at:
http://www.netbeans.org