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.
Currently the GUI lets you switch between: - plain tree view - package view with full package names You can also display a compacted package view using -J-Dorg.netbeans.spi.java.project.support.ui.packageView.TRUNCATE_PACKAGE_NAMES=true I think Jano had mentioned a third view mode he wanted to see supported in the GUI; I think it was the same as the regular package (list) view but omitting any common prefix (ending in '.') of all package names, leaving the tooltips to show the common prefix if it is not obvious. A fourth possible mode that has been requested in issue #42151 is more similar to the tree view, except that wherever a folder "A" has exactly one child, another folder "B", the two are collapsed into one node "A.B" (and so on recursively). (If TreeView supported it, it would be ideal to have each package name display as much as possible, but collapse enough to fit horizontally within the available space, with the full name displayed in an overlay-like tooltip when the node was selected. However this is beyond the current capabilities of the Explorer controls.) So we have e.g. TREE: <root> + org + netbeans + modules + java + JavaDataObject.java + resources + mf-layer.xml PLAIN PACKAGE: <root> + org.netbeans.modules.java + JavaDataObject.java + org.netbeans.modules.java.resources + mf-layer.xml REDUCED PACKAGE: <root> + ....java + JavaDataObject.java + ....java.resources + mf-layer.xml REDUCED TREE: <root> + org.netbeans.modules.java + JavaDataObject.java + resources + mf-layer.xml
I've integrated the tree view into 4.1, but the other two views will go into future release.
*** Issue 56493 has been marked as a duplicate of this issue. ***
It seems to me there are two orthogonal features here. Truncated names, and Compacted (or Reduced) Trees So a Fifth combination is also possible: Truncated REDUCED TREE: <root> + ....java + JavaDataObject.java + resources + mf-layer.xml
*** Issue 59142 has been marked as a duplicate of this issue. ***
*** Issue 82391 has been marked as a duplicate of this issue. ***
*** Bug 201404 has been marked as a duplicate of this bug. ***
Perhaps there should be an SPI to add alternatives to the regular flat package view (default) and tree mode, which are available via context menu in the (empty part of the) Projects tab. Compare o.n.m.ant.freeform.spi.ProjectNature.getSourceFolderViewStyles.
The problem with all of these solutions is that none of them will please everyone, or likely even the majority. The simplest solution that will please the most people is the suggestion advanced in issue #201404 and others; just allow the user to specify abbreviations for specific package names.
*** Bug 88660 has been marked as a duplicate of this bug. ***
*** Bug 70455 has been marked as a duplicate of this bug. ***
*** Bug 98052 has been marked as a duplicate of this bug. ***
*** Bug 202209 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > The problem with all of these solutions is that none of them will please > everyone, or likely even the majority. The simplest solution that will please > the most people is the suggestion advanced in issue #201404 and others; just > allow the user to specify abbreviations for specific package names. IMHO, the "REDUCED TREE" type options which save vertical real estate and still shows the tree structure is important.
(In reply to comment #13) > IMHO, the "REDUCED TREE" type options which save vertical real estate and still > shows the tree structure is important. That's the good thing about the suggestion advanced in issue #201404. You can set the abbreviation to anything you want, so if you want to use an abbreviation that still shows the tree structure you can.
Having a glimpse at the way IntelliJ idea handles this, it might be a really good way to please everybody: When in a package view, show only the changes from the parent to the next child and ignore empty packages. Example: org.netbeans.foo.bar.baz.bof.Sample is a class, with bar and bof packages beeing empty + -- org.netbeans + SomeClass + -- foo -- AnotherClass + -- bar.bof -- Sample This saves a lot of screen estate and makes lookup fast without the need to guess abbrevations
(In reply to comment #15) The problem with that approach is that if SomeClass and AnotherClass aren't there, you're once again stuck with a (potentially) really long package name. I still think the simplest solution and the solution that's most acceptable to all parties is to just allow users to specify abbreviations for package names. It works well in Eclipse, and the users like it, so Netbeans should just copy it.
Obviously this is a matter of taste, I think the plain shortening is less productive/smart than leaving out non-relevant information completely as described in my prior comment. Perhaps making that choice configurable would serve all users.
> leaving out non-relevant information completely as > described in my prior comment AFAICT this option is described in this issues description. Jesse calls it "REDUCED TREE" in his examples. (I really like this display mode)
(In reply to comment #18) Yeah, the "reduced tree" stuff looks good to me, now that I'm looking at it.
Working on "reduced tree" style, which seems effective and popular; other features such as automatic or customizable truncation can be filed separately if still needed.
core-main #ea7bd031f9e3 Not the default for now; needs to have bugs shaken out, and not clear which mode most people would choose anyway.
Integrated into 'main-golden', will be available in build *201202180400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/ea7bd031f9e3 User: Jesse Glick <jglick@netbeans.org> Log: #53192: option to display packages as a "reduced tree".
It's probably bad form to verify someone else's bug, but it looks good to me...
Whoops, you could have verified that yourself. :P
(In reply to comment #23) > It's probably bad form to verify someone else's bug To the contrary, only the actual benefactor of a fix can really verify it.