Reduced Tree View in NetBeans IDE 7.2

Right-click within the Projects window in NetBeans IDE 7.2 and from the "View Java Packages As" menu, you can now choose "Reduced Tree".

I never really understood the difference between "Reduced Tree" and the already existing "Tree". But it makes sense when you see it. Here's Reduced Tree view:

And here's Tree view. Tree view is just a plain folder tree, like you would see in the Files window; it scales well and has a clear UI, but you have to expand a lot of nodes in a typical project to find anything.

What's cool is that your selected package view is persisted across restarts of the IDE.

To be complete, here's the List view. List view is a flat list of all packages with no nesting displayed. It can make it quicker to jump to a particular package, though as you can see it can take up a lot of horizontal space. List view can also become overwhelmingly long - and slow to compute - in a very large project.

Seems to me like the new Reduced Tree view combines the best of the Tree view with the best of the List view!

Related issue: http://netbeans.org/bugzilla/show_bug.cgi?id=53192

Comments:

Your screenshots mixed up "List" view with "Tree" view, which makes the explanation confusing!

"Tree" is just a plain folder tree, like you would see in Files; it scales well and has a clear UI, but you have to expand a lot of nodes in a typical project to find anything.

"List" is a flat list of all packages with no nesting displayed. It can make it quicker to jump to a particular package, though as you can see it can take up a lot of horizontal space. (-J-Dorg.netbeans.spi.java.project.support.ui.packageView.TRUNCATE_PACKAGE_NAMES=true can be used as a partial workaround.) A "List" can also become overwhelmingly long - and slow to compute - in a very large project.

"Reduced Tree" is a variant of "Tree" with the special rule that if a folder has exactly one child, also a folder, then the child's contents are spliced into the parent and the child name appended (and this reduction repeated so long as it applies). This style has long been available in some other IDEs and people often requested this or something like it. I am sure the name is not completely self-explanatory - maybe 7.3 could use a different name, and if most people like it, even turn it on by default.

"Reduced Tree" relies on the assumption that in typical Java projects, most or all of the classes (and resources) are beneath one package prefix with several path components, with a relatively shallow structure beneath that. So you get the "boilerplate" com.mycorp.mydivision.someproject.somemodule stuff out of the way in a single node with one long label that can extend past the right edge of the viewport without much loss of usability.

You can always of course scroll the viewport to see the rest of the label, or hover over the node with the mouse to show the full name in a tool tip, but both are awkward operations you would not want to have to do all the time, hence the TRUNCATE_PACKAGE_NAMES hack in the list view. Nicer would be if org.openide.explorer.TreeView automatically shrunk long labels to fit inside the viewport, with the tooltip showing the full text; this would require some API for the Node to specify a domain-specific shrinking algorithm. For package names, it is preferable to shrink earlier components than later; and for English or English-like text, deleting vowels is much better than deleting consonants. Tim Boudreau was at one point playing with a patch that did something like this, producing e.g. "c…mcr…mdv…smprjct.somemodule", with the exact text to be elided varying dynamically as the viewport was resized or scrolled.

Beware that Java refactoring operations work differently depending on which view you are using. The general principle is to try to make the refactoring do what it will look like it should based on the view, but this is subject to interpretation. So for example "Rename" on a package in "List" view changes the locations (and package declarations) of *.java directly in that package, but not "subpackages" - which is fine according to the Java language spec (which assigns no special meaning to package names), resulting in an apparent rename of the node you selected and no others, but this is rarely what the user actually wanted to do. "Rename" in "Tree" view, by contrast, will apply the rename refactoring to all Java sources in subpackages too; this is more likely what you wanted to do, but on the other hand in this view you cannot rename com.mycorp.mydivision.someproject to com.mycorp.mydivproject in one operation. Similar considerations apply to "Delete", "Copy", "Move", drag-and-drop, etc. Not all these operations work exactly like you might expect in "Reduced Tree" mode in 7.2; to fix the corner cases, some additions are needed in the Refactoring API. Arguably the UI should be changed so that any gestures initiating a Java-aware refactoring in any view should just bring up a dialog allowing you to fine-tune all the parameters, so that for a rename refactoring any segment of the package name can be renamed to any other dot-separated list of any size, with or without rename of subpackages.

Posted by Jesse Glick on June 17, 2012 at 07:41 AM PDT #

Hi Jesse, thanks, fixed the screenshots and interwove some of your excellent comments into the blog entry. Why not start your own blog with NetBeans tips and tricks and other NetBeans insights?

Posted by Geertjan on June 17, 2012 at 01:16 PM PDT #

Is that what Eclipse had for almost 10 years now? The option was called "show empty packages".

Posted by alex on June 18, 2012 at 05:42 AM PDT #

Thank you, is just what I need.

Posted by guest on August 13, 2012 at 10:14 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
12
13
14
23
24
25
26
27
28
29
30
   
       
Today