Community
Participate
Working Groups
This is for future, but would be really really nice. (it has probably been reported before by someone from the SWT team because our setup makes the need for this feature so obvious). Please add a filter to the Packages view that reorganizes the view so that PACKAGES are at the top level instead of FOLDERS. The current organization of the packages view spreads our SWT packages out over all of the folders that they are in, and it makes it hard to see all of the SWT packages. A much more useful view would be to have everything grouped into their containing package. For example, we have had to split the SWT packages across platform lines, and we therefore have folders for 'common', 'win32', 'motif', etc. When the .classpath is specified for Windows, only 'common' and 'win32' folders are displayed (with the cute little folder icon with a package peeking out of them). So we end up with 2 'folders' for each package. This looks like: Eclipse SWT/common Eclipse SWT/win32 Eclipse SWT Printing/common Eclipse SWT Printing/win32 Eclipse SWT Program/common Eclipse SWT Program/win32 Eclipse SWT Drag and Drop/common Eclipse SWT Drag and Drop/win32 So in order to find, say, the widgets package, you have to expand BOTH Eclipse SWT/common and Eclipse SWT/win32 folders, and you are constantly having to switch back and forth between the folders to see all of the classes in the package. This is sub-optimal. The optimal packages view would merge the folders by package, so we would only have to go to the package and expand one thing. Of course, it needs to be optional, because there are (rare) times when you do care what folder something is in (such as when you are organizing the folders in the first place). NOTES: VI (6/19/2001 4:43:32 PM) For an example of what it should look like, see the "bin" folder. CM (6/19/2001 4:43:53 PM) But make sure that the .class files from "bin" are not also showing in the packages. SN (6/19/2001 4:44:40 PM) If this filter is on, then search, open type, etc., etc., should only find what is on your classpath. (i.e. currently when we say "Open Type" we have to select the type for win32, motif, gtk, photon, ...) A whole new view that showed only packages and their classes (in their hierarchies!) would make me very happy.
moved to 'active'
PRODUCT VERSION: 125
The problem is that the packages view is designed to reflect the projects build path. That's why we "have" to show the folders. Possible solutions are: - we allow creating a type hierarchy on a set of packages. This would address Steve cases. - the new browser perspective allows to define the input of the packages view. Then we could merge same package fragments to one logical packages and could show a list of packages that have different source folders as their parents. Martin, can you please check if we can implement the type hierarchy case. If done please move to Dani so that he can comment on the browser perspective.
if hierarchy view is opened on a package, it now contains the types of all packages in the project with the given name. Moving to Dani
Martin's change solves SN's wish but this can also be misleading for users. How do you explain that using "Open Type Hierarchy" on a package uses logical grouping while all other actions don't? Regarding the behavior in the Java Browsing view: the packages with same name are not merged but all appear together (with same name). No browsing or opening of source folders is needed if the project (e.g. SWT) is selected. You see in the Projects view from which source folder a package comes from (e.g. org.eclipse.swt.internal) or you can in the status bar. Merging is currently not possible because there's no Java Model support (i.e. no Java element representing a logically merged package). It could be hacked but those hacks would have to be distributed in several places to make error ticks and actions work and to reflect Java model changes in the UI.
defer
reopen
Experimental stage/code has been released to HEAD for Packages view (Java browsing perspective). Also allows to switch between list and tree layout. Will be in builds starting N20021129. Problems exist mostly with tree layout.
Released to build I20021203
