Community
Participate
Working Groups
Views can be opened, moved around, and closed on an individual basis by the user. If the user wishes to reposition several views, each view must be moved and resized individually. There is no public API for several related views to be programmatically tied together in as generic way as possible so that a single new view can be composed of several other views. For example, the JDT "Projects", "Packages", "Types", and "Members" views are all interrelated, and could be tied together as a single composite view to be opned, moved, and closed as a single unit. To accomplish this, we created a CompositeViewPart to provide this composite functionality. A patch containing this code has been attached. Please consider this functionality for inclusion in the Eclipse 3.0 M2 build.
Created attachment 5325 [details] new CompositeViewPart with supporting class
I have the following concerns with this suggested change. 1. This limits how the user can manipulate views. Of course, the same argument could be applied for nested editors. However, I would want to understand the particular concrete use cases that you have for this in your product in order to consider adding something like this to Eclipse. Have you considered refactoring the nested views as nested viewers, and implementing the outer view as a regular view containing the nested viewers? This could be done without introducing the notion of nested views. A good example of this is the JDT Hierarchy view. 2. The code appears to draw a gradient for nested panes. This blurs the distinction between active parts. See guideline 1.2 at: http://eclipse.org/articles/Article-UI-Guidelines/Index.html
We have investigated into composite parts when we implemented the Java perspective layouts. We eventually stop going down this path, because: * users need to be able to fully customize a perspective even when there are composite parts. This includes adding and removing a part from a composite, creating a new composite etc. We couldn't come up with a satisfying solution that doesn't introduce a lot of complexity. It doesn't look like the patch covers the user configurability problem. * we have eventually found that "flat" parts are more flexible to the user (Java Browsing perspective) and that nested viewers work well (type hierarchy)
Reassigning bugs in component areas that are changing ownership.
Please reopen with concrete use cases if this enhancement request is still valid. (Or is this a dupe of the infamous bug 46207?)
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
