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 NetBeans 5.5 it is possible to expand a .java file's node in the Projects window and see a list of classes contained in that .java file. Those classes can then be expanded to see the Fields, Constructors, Methods, and Beans in the class. This feature has been removed. Please bring it back. While it is true that the information can be seen in the Navigator window, not everyone uses the Navigator window. Or has the Navigator window open all the time. Note that for users who might consider converting from Eclipse, the inability to expand .java files in the Projects window could lessen their interest in NetBeans since Eclipse provides expansion in its Project Explorer (which is equivalent to the Projects window in NetBeans). A somewhat related issue: http://www.netbeans.org/issues/show_bug.cgi?id=97603
This affects more than just the classes. The BeanInfo Editor is not accessible because of this. This tool is a must have. This will kill productivity for JavaBeans in the IDE. This has nothing to do with using them but creating and designing them. I have moved it to a P1 as this should block a 6.0 release. This is a regression and breaks functionality.
Adding UI kw since (I think) it was removed according to some HIE decision. If you think it's blocker for 6.0 then make it DEFECT (but not P1).
So, I consider this a defect, and a regression since this is present in 5.X and now we can't use this features, mainly BeanInfo Editor. I consider this a P1, since we can't use the BeanInfo Editor in any way, but as you say that this is not a P1, I lower this to P2.
You cannot be serious, guys. It is not the first time a very useful NB feature is removed without asking the community first. Not only bring it back, but please don't remove stuff just because some department think it nobody cares about it; we do.
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. <smallrant_nothingmajor>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.</smallrant_nothingmajor>
I should follow the last comment with: thanks "everybody" for all the hard work.
This same issue affecting other files is really starting to limit A LOT of functionality. It affects moving classes around NetBeans Module Development in the Layer which affects Java file among other things. Now the layer editor is just not there...different issue really, but caused by the same lack of reviewing needs before jumping in head first with a change.
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. Who made this determination and based on what? I'm sorry for getting a little upset 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. 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, 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.
*** This issue has been marked as a duplicate of 96196 ***