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 42151 - Provide option to display tree structure in logical view
Summary: Provide option to display tree structure in logical view
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker with 8 votes (vote)
Assignee: Tomas Zezula
URL:
Keywords: RELNOTE
: 46062 47630 47635 47962 48904 50510 51559 (view as bug list)
Depends on: 48618 53192
Blocks: 41535
  Show dependency tree
 
Reported: 2004-04-20 01:50 UTC by Jesse Glick
Modified: 2005-01-10 15:59 UTC (History)
14 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2004-04-20 01:50:29 UTC
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.
Comment 1 swb 2004-04-20 08:48:45 UTC
I voted for this issue in respect of making it an option.
Comment 2 gugrim 2004-07-28 17:44:23 UTC
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.
Comment 3 Jesse Glick 2004-07-28 22:25:31 UTC
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.
Comment 4 silviobierman 2004-07-29 13:37:17 UTC
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
Comment 5 Jesse Glick 2004-08-14 16:08:15 UTC
*** Issue 46062 has been marked as a duplicate of this issue. ***
Comment 6 _ wadechandler 2004-08-14 23:04:07 UTC
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.
Comment 7 Petr Hrebejk 2004-08-21 11:48:06 UTC
*** Issue 47630 has been marked as a duplicate of this issue. ***
Comment 8 kjmcdonald 2004-08-24 16:43:01 UTC
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
Comment 9 Jesse Glick 2004-08-24 23:59:29 UTC
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.
Comment 10 Martin Matula 2004-08-25 16:45:25 UTC
Please involve the refactoring team in design decisions - this will
have impact on refactoring actions.
Comment 11 Jesse Glick 2004-08-25 21:15:07 UTC
*** Issue 47962 has been marked as a duplicate of this issue. ***
Comment 12 silviobierman 2004-08-26 10:09:56 UTC
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.
Comment 13 Martin Matula 2004-08-26 10:27:48 UTC
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.
Comment 14 silviobierman 2004-08-26 10:36:37 UTC
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.
Comment 15 klosels 2004-08-26 11:14:21 UTC
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.
Comment 16 Martin Matula 2004-08-26 15:50:35 UTC
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.
Comment 17 Jesse Glick 2004-08-27 02:43:27 UTC
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.
Comment 18 Martin Matula 2004-08-27 09:18:31 UTC
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.
Comment 19 Petr Jiricka 2004-08-27 10:08:43 UTC
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.
Comment 20 Petr Hrebejk 2004-08-31 09:59:12 UTC
*** Issue 47635 has been marked as a duplicate of this issue. ***
Comment 21 athompson 2004-09-02 12:47:24 UTC
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?
Comment 22 Petr Hrebejk 2004-09-02 13:47:16 UTC
Do you mean something like MainMenu->Window->Select Document In ?
Comment 23 Jesse Glick 2004-09-02 15:46:58 UTC
(i.e. Ctrl-Shift-2)
Comment 24 athompson 2004-09-02 16:01:35 UTC
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.
Comment 25 mli6688 2004-09-03 19:56:55 UTC
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.
Comment 26 Moruk 2004-09-06 10:57:03 UTC
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.
Comment 27 athompson 2004-09-06 13:57:31 UTC
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).
Comment 28 Jesse Glick 2004-09-07 18:19:24 UTC
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.
Comment 29 Jesse Glick 2004-09-07 23:06:09 UTC
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.
Comment 30 Jesse Glick 2004-09-08 00:22:47 UTC
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
Comment 31 John Jullion-ceccarelli 2004-09-08 14:19:46 UTC
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.
Comment 32 Jesse Glick 2004-09-08 14:56:45 UTC
Sounds fine. Seems more appropriate material for web-based tips and
tricks than for the bundled online help, which should be more
conservative.
Comment 33 miks 2004-09-10 19:15:16 UTC
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.
Comment 34 Jesse Glick 2004-09-10 19:43:21 UTC
miks - as already mentioned in this issue, a live switch in the GUI
will have to wait. It is too late for 4.0.
Comment 35 David Konecny 2004-09-13 09:26:27 UTC
*** Issue 48904 has been marked as a duplicate of this issue. ***
Comment 36 tboerkel 2004-10-01 13:38:22 UTC
The commandline switch does not seem to work in Beta 2.
Comment 37 Jesse Glick 2004-10-04 17:01:16 UTC
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.
Comment 38 Jesse Glick 2004-10-16 14:58:09 UTC
*** Issue 50510 has been marked as a duplicate of this issue. ***
Comment 39 David Strupl 2004-11-23 00:23:47 UTC
*** Issue 51559 has been marked as a duplicate of this issue. ***
Comment 40 Jesse Glick 2004-11-29 17:20:11 UTC
Preferred by Jan 05.
Comment 41 Milan Kubec 2004-12-02 15:23:00 UTC
Release notes should mention the property for setting tree:
-J-Dorg.netbeans.spi.java.project.support.ui.packageView.USE_TREE_VIEW=true
Comment 42 Tomas Zezula 2005-01-10 15:59:54 UTC
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