Community
Participate
Working Groups
Both the public API for showing views org.eclipse.ui.IWorkbenchPage#showView(String viewIdentifier) and the internal class for doing the same org.eclipse.ui.internal.ShowViewAction show views at a location predefined in the plugin manifest. We want to programmatically show a view relative to another view, but that relationship is not known until the user actually selects one of our commands to perform the operation. For example, we can specify that our view appear stacked on top of another view in a known perspective, but we cannot specify such a relationship for perspectives that are not known at build time such as custom user perspectives. For this purpose, I created org.eclipse.ui.actions.ShowViewAction based upon the original internal ShowViewAction type. The new ShowViewAction supports the original's behavior plus the ability to programmatically specify where the new view should show up in relation to an existing view. This new action is based upon Eclipse 2.1 and so might need some changes for Eclipse 3.0 M2, but no other classes would need to be modified. Both versions of the ShowViewAction can co-exist peacefully so there would be no need to immediately remove the old ShowViewAction or change any code that relies on it. Please consider this new ShowViewAction for inclusion in the Eclipse 3.0 M2 build.
Created attachment 5285 [details] The new ShowViewAction source
I have the following concerns with the suggested enhancement: 1. It provides an action to open a view, giving more control over where it's placed. Normally we provide API on the main interfaces and/or extension points, rather than as actions. 2. This doesn't add any new constraints for when the user opens the view using the regular Show View actions. We could consider augmenting the XML with layout constraints that are independent of perspectives. E.g. always position Package Explorer and Navigator in the same folder. Would that address your needs or would you still need more control for particular actions? 3. Providing the new constraints via an action means that there will be duplicate and inconsistent actions for showing views in the UI. 4. As with bug 39513, new API should not be introduced as actions, but should go on the primary interfaces, e.g. an enhanced showView method on IWorkbenchPage, or inhanced attributes on the views extension point. It would help to have some concrete use cases to back up the proposed enhancement.
Not for 3.0.
*** Bug 98131 has been marked as a duplicate of this bug. ***
Reassigning bugs in component areas that are changing ownership.
(In reply to comment #2) > It would help to have some concrete use cases to back up the proposed > enhancement. Yes. Feel free to reopen if you have concrete use cases.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
