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.
Several users on nbusers have strongly requested the option to display Java sources in the logical view in an NB 3.x-like tree structure, rather than the flattened package view. From Lars Klose: ---%<--- One thing that striked me when opening a project for the frist time was the way packages are displayed: each package seperately with the possibly long, boring prefix like 'com.acme.myproject.subproject'. That is one thing I absolutely _hate_ about Eclipse. Not only is it clumsy to work with, but it disrespects that the package structure IS tree-like, so why shouldn't it be displayed as such? At least an option to switch the appearance of Source Packages is a MUST in my opinion. ---%<--- I have no idea what proportion of users feel this way, of course.
I voted for this issue in respect of making it an option.
A good idea to make it optional. What I'd like to see is the option to show a semi-flat tree, meaning that packages with only a single sub-package are combined into one node, recursively. Example: Normal tree: se . grim . . doi . . . model . . . . DoiBroker.java . . . view . . . . DoiView.java Semi-flat tree: se.grim.doi.model . DoiBroker.java se.grim.doi.view . DoiView.java This way you don't have to expand the first few levels since they anyway often just your reversed domain name.
Plain tree mode should at least be possible for D with a system option at startup; GUI-visible option (and potential change of default, depending on feedback) for E. Re. semi-flat structure: interesting idea, though some more work to implement. (At least as much as the current flat package view: lots of nontrivial decisions about how copy & paste work, refresh semantics, ad nauseam.) Has been proposed at various times but this is a relatively clear formulation of it. I presume your example should actually have looked like + se.grim.doi | +-+ model | | | +-o DoiBroker.java | +-+ view | +-o DoiView.java since se/grim/doi/ here has multiple children.
I also think it should look like that. Let's not forget that this is how it used to work in NB3 when you did "add existing" on the project view and selected a non-root source directory. V3.6 works almost the same but labels it as "doi" only instead of "se.grim.doi" so I always change the name after adding it. This was a quite recent regression. I don't see the problem with copy-paste/drag-drop, you always go from one package name to another. The actions remain the same, only the presentation differs. Silvio Bierman
*** Issue 46062 has been marked as a duplicate of this issue. ***
I think two ways should be sufficient. Either show all packages seperately or show a tree and allow the user to expand that out how they need to as they are working (like 3.6). Most projects are going to be under one main package com.whatever (net. or org. whatver). Showing every single package instead of a sigle tree doesn't scale very well to large projects. We have quite a number of packages in our "common" package. It may or may not need to be broken out into more projects, but they are all in the common set, so it makes sense to keep them together so users only need to update one package to update our common lib. Anyways, I argue that showing every single package doesn't scale well to a large project as it is just too much to look at at one time in a scroll pane.
*** Issue 47630 has been marked as a duplicate of this issue. ***
In NB 3.6, my projects were organized so that they were all in seperate Java packages. With some packages being used by more than one Project. Because of this I had laid the files out on the disk in one src tree, and used only the package directories to keep them seperate. I mounted the source tree once in NB3.6. I like the way NB4.0 Projects are going now though. And I just recently split out all the projects into different project directories with their own 'src' directory. but what I reall miss is that 'overlayed' look at the sources. Would it be possible to have (maybe a seperate tab in the file browser) a view of your sources where the main project, and all the sub or dependent projects sources are overlayed on top of each other so that there is only one package hierarchy? Example: Given Projects: A/ src/ com/ acme/ projA/ A.java B/ src/ com/ acme/ projB/ B.java Utils src/ com/ acme/ Utils/ foo.java bar.java Instead of seeing a tree like: A com.acme.projA A.java B com.acme.projB B.java Utils com.acme.Utils foo.java bar.java Could we see: com acme projA A.java projB B.java Utils foo.java bar.java
Re. overlaid look across multiple projects - not possible in 4.0, and not related to this RFE at all. May be considered for a future release.
Please involve the refactoring team in design decisions - this will have impact on refactoring actions.
*** Issue 47962 has been marked as a duplicate of this issue. ***
In response to Martin: This is not about multiple projects. When composing a projects source tree you often want to merge non-root packages in a single tree. The view Jesse pictured is the only logical and practical way of presenting this.
Silvio, changes from flattened view to tree view redefine what refactoring rename on a tree node means. I.e. rename org.mypackage in the flattened view correctly repackages just classes in org.mypackage. But in tree view if you do rename on org +-- mypackage it should repackage (rename packages for) all classes in org.mypackages and all subpackages recursively. That's why these decisions affect the refactoring functionality.
Martin, I understand that this has consequences for refactoring. But consider the alternative. The same package can appear more than once in the project view and it is not clear what renaming the package on one of these nodes means. Refactoring is very usefull functionality and a welcome addition. If usability gets in its way by causing ambiguities I would prefer refactoring to fail with an error (or better yet, ask the user what he really wants) instead of limiting functionality to facilitate refactoring.
This issue is about the view or display - for the user this is in the first place unrelated to how other features (like refactoring) work internally. Designing the project view according to the needs of a specific feature is not the way it should be done and indicates a design flaw IMHO. Refactoring should internally be decoupled from a specific GUI representation (which it hopefully is), just the actions to invoke it need to be coupled to the GUI. As this admittedly touches the UI representation of refactoring actions (or their behaviour) as well: UI actions have to be either unambigous or the user must have the option to decide, therefore: +1 for Silvios suggestion of resolving ambiguities by asking the user. Having that there should be no other reason (related to refactoring) for not having the tree-like view.
People, all I am asking is that the refactoring team should be involved in decision making to be able to come up with a realistic schedule. Because there are some resources that will need to be spent - if not for providing an intuitive refactoring support for tree view, we will at least need to work with UI team to make sure people don't get confused by how the refactoring works in that case. That's it. Re. "The same package can appear more than once in the project view and it is not clear what renaming the package on one of these nodes means.": It means renaming of that specific node - i.e. all classes under that node are repackaged and moved to the directory corresponding to the new package. Why is it not clear whether this is correct? It becomes more tricky when you try to merge packages from all source roots - that's another enhancement request which affects the refactoring functionality since the sematics of the rename action is again different from the two scenarios already described. So, I do not want to block this feature at all. All I want is that we consider the impact and think about how we should deal with it.
IMHO the relationship of the rename refactoring to the package display is superficial and should not be made more complicated than it needs to be. I agree with Lars that the best state is that the package rename dialog always asks you (with a checkbox) whether you want to move subpackages as well (if there are any to move). This is desirable whatever view you happen to be using. There is no need to force an artificial analogy too far - a flat package node is just a convenient display mechanism for a section of a tree. Since the rename dialog currently always renames only the single package, never subpackages, leave it that way. (Maybe put a simple text label into the dialog emphasizing that fact.) If and when the refactoring team has time to provide an option to rename subpackages too, then great - do it; if not for 4.0, fine. Again, I would second Lars' note that the display of packages is used for many purposes by a user while working in the IDE; the rename refactoring is nice but it is just one feature, and not one that is likely to be used routinely for that matter. It is certainly not central enough to constrain the basic display of a project. I would like to provide at least a system property (startup switch) that would permit a simple tree view (*) to be displayed in the Projects tab in place of the current flat package list wherever Java packages are displayed. I still need to try to make a patch to see how much work is involved. For 4.0 it would not be considered a supported feature and would probably receive only informal community testing. (*) The alternately proposed "compact tree view" would be nice but it is impossible for 4.0, I think - the logic is rather more complex than for the simple tree view, and it is too risky at this point.
I guess it is up to UI team to decide what's best for users. While I understand that people who know about this problem (such as Lars, Jesse and others CC'ed to this issue) could live with the rename refactoring as is, I can imagine (from the bugs that were already filed against refactoring module in the past by NetBeans QA team), that to most users not involved in this particular discussion it would be quite confusing. Probably it is fine to have the tree view turned on by a system option, which makes it clear that it is not a first class feature of the IDE thus users would not expect to everything work perfectly. I don't know. As I said, I think UI team should say what's the expected/acceptable behavior from users' point of view. And we need to have a specification for that, so that we have something we can point people to if they complain.
There is a related enhancement request #46063 about expanding packages in the tree view. Can this be considered for the Files tab at least? How difficult is that to implement? Thanks.
*** Issue 47635 has been marked as a duplicate of this issue. ***
this would be nich as an option, but i happen to like the package view just the way it is. of couse, i've been using eclipse for the last few years, but isn't the whole objective to steal users from other IDEs? :) why not add a shortcut for the source in the file view or something?
Do you mean something like MainMenu->Window->Select Document In ?
(i.e. Ctrl-Shift-2)
no, but that's a nice feature i wasn't aware of. thanks! :) i meant, have something like the file view, but the roots are all the source folders in the current project.
why don't we have options to choose which view to use, like it is in IDEA. It is very stupid to dump one part of users in favor of another when both can co-exist.
I have the same problem in both views. The same problem in the old tree view and the same problem in the new flattened view. The problem is, that I always have to resize the horizontal size of that panel to a very big size. I have always big package structures like de.lmu.pms.project.engine ... . In the old view the files have been to the far right because of the tree structure. In the new view I also have to resize it to the far right, because I else can not see the full name of the packages. So, regardless of what view will happen to be in 4.0, IMHO the important think is to fix this problem.
i agree with moruk's last comment, although i don't see how to fix it. it's also a big part of what makes the slide-in panels unusable (see issue 47334 and issue 44733).
For Moruk and alvint: try -J-Dorg.netbeans.spi.java.project.support.ui.packageView.TRUNCATE_PACKAGE_NAMES=true. Helps somewhat. This is not a supported option - your mileage may vary.
Working on implementing a startup switch: -J-Dorg.netbeans.spi.java.project.support.ui.packageView.USE_TREE_VIEW=true *Not* supported but seems to work OK.
So I have added the special startup switch which causes package trees to be shown as trees. For promo-E we can consider a collapsed tree view as another alternative, and making the choice a supported GUI switch (which implies ability to switch at runtime as well - probably not hard, though not trivial). John Jullion, consider mentioning the switch somewhere where users can find it, but be sure to emphasize that it is not supported or fully tested, and anyone reporting a bug with this switch on must mention that fact in the bug report. Main fixes in java/project (PackageView), incl. making the Java target chooser no longer rely on the same node structure for its combo box (which it never really needed to anyway, and which is just overhead): committed 1.5 java/project/arch.xml committed 1.22 java/project/src/org/netbeans/modules/java/project/Bundle.properties committed 1.18 java/project/src/org/netbeans/modules/java/project/JavaTargetChooserPanelGUI.java added 1.1 java/project/src/org/netbeans/modules/java/project/PackageDisplayUtils.java added 1.1 java/project/src/org/netbeans/modules/java/project/PackageListView.java committed 1.6 java/project/src/org/netbeans/spi/java/project/support/ui/Bundle.properties committed 1.13 java/project/src/org/netbeans/spi/java/project/support/ui/PackageRootNode.java committed 1.8 java/project/src/org/netbeans/spi/java/project/support/ui/PackageView.java committed 1.40 java/project/src/org/netbeans/spi/java/project/support/ui/PackageViewChildren.java added 1.1 java/project/src/org/netbeans/spi/java/project/support/ui/TreeRootNode.java committed 1.17 java/project/test/unit/src/org/netbeans/spi/java/project/support/ui/PackageViewTest.java Fixes in junit module to not presume that all Java sources are located at second level in the tree provided by PackageView, which there was never any sort of API guarantee they would be: committed 1.2 junit/src/org/netbeans/modules/junit/wizards/JavaChildren.java removed 1.1 junit/src/org/netbeans/modules/junit/wizards/LogicalViewRootChildren.java committed 1.12 junit/src/org/netbeans/modules/junit/wizards/SimpleTestStepLocation.java Fixes of refactoring module to produce a package list for the Move Class refactoring directly, rather than making assumptions about the structure of the package view, which is an illegal use of the API: committed 1.5 refactoring/build.xml committed 1.8 refactoring/nbproject/project.xml added 1.1 refactoring/src/org/netbeans/modules/refactoring/resources/package.gif added 1.1 refactoring/src/org/netbeans/modules/refactoring/resources/packageEmpty.gif added 1.1 refactoring/src/org/netbeans/modules/refactoring/resources/packagePrivate.gif added 1.1 refactoring/src/org/netbeans/modules/refactoring/resources/packagePublic.gif committed 1.28 refactoring/src/org/netbeans/modules/refactoring/ui/Bundle.properties committed 1.11 refactoring/src/org/netbeans/modules/refactoring/ui/MoveClassPanel.java added 1.1 refactoring/src/org/netbeans/modules/refactoring/ui/PackageDisplayUtils.java added 1.1 refactoring/src/org/netbeans/modules/refactoring/ui/PackageListView.java
I will mention it in the Online Help page that deals with the Projects window, but would rather not give it any higher visibility since it really hasn't been tested.
Sounds fine. Seems more appropriate material for web-based tips and tricks than for the bundled online help, which should be more conservative.
Tree view in the project window is really missing, making it as a startup switch might be fine, but I think that it should be possible to switch between these view while working, that is, it should be possible to switch between these view thought the UI. I really don't like eclipse, but at least this is a trivial functionality that exist there.
miks - as already mentioned in this issue, a live switch in the GUI will have to wait. It is too late for 4.0.
*** Issue 48904 has been marked as a duplicate of this issue. ***
The commandline switch does not seem to work in Beta 2.
I just tried -J-Dorg.netbeans.spi.java.project.support.ui.packageView.USE_TREE_VIEW=true in a current dev build and it worked fine.
*** Issue 50510 has been marked as a duplicate of this issue. ***
*** Issue 51559 has been marked as a duplicate of this issue. ***
Preferred by Jan 05.
Release notes should mention the property for setting tree: -J-Dorg.netbeans.spi.java.project.support.ui.packageView.USE_TREE_VIEW=true
I've added option to switch the logical view either to package view or to the tree view. Checking in project/src/org/netbeans/modules/java/project/Bundle.properties; /cvs/java/project/src/org/netbeans/modules/java/project/Bundle.properties,v <-- Bundle.properties new revision: 1.24; previous revision: 1.23 done RCS file: /cvs/java/project/src/org/netbeans/modules/java/project/PackageViewSettings.java,v done Checking in project/src/org/netbeans/modules/java/project/PackageViewSettings.java; /cvs/java/project/src/org/netbeans/modules/java/project/PackageViewSettings.java,v <-- PackageViewSettings.java initial revision: 1.1 done RCS file: /cvs/java/project/src/org/netbeans/modules/java/project/PackageViewSettingsBeanInfo.java,v done Checking in project/src/org/netbeans/modules/java/project/PackageViewSettingsBeanInfo.java; /cvs/java/project/src/org/netbeans/modules/java/project/PackageViewSettingsBeanInfo.java,v <-- PackageViewSettingsBeanInfo.java initial revision: 1.1 done RCS file: /cvs/java/project/src/org/netbeans/modules/java/project/PackageViewTypeEditor.java,v done Checking in project/src/org/netbeans/modules/java/project/PackageViewTypeEditor.java; /cvs/java/project/src/org/netbeans/modules/java/project/PackageViewTypeEditor.java,v <-- PackageViewTypeEditor.java initial revision: 1.1 done Checking in project/src/org/netbeans/modules/java/project/layer.xml; /cvs/java/project/src/org/netbeans/modules/java/project/layer.xml,v <-- layer.xml new revision: 1.16; previous revision: 1.15 done RCS file: /cvs/java/project/src/org/netbeans/modules/java/project/packageViewSettings.settings,v done Checking in project/src/org/netbeans/modules/java/project/packageViewSettings.settings; /cvs/java/project/src/org/netbeans/modules/java/project/packageViewSettings.settings,v <-- packageViewSettings.settings initial revision: 1.1 done Processing log script arguments... More commits to come... Checking in project/src/org/netbeans/spi/java/project/support/ui/PackageView.java; /cvs/java/project/src/org/netbeans/spi/java/project/support/ui/PackageView.java,v <-- PackageView.java new revision: 1.9; previous revision: 1.8 done