Community
Participate
Working Groups
I'd like to be able to have multiple instances of the same view within one workbench window. An example of this is an 'explorer like' view where I want to have the ability to have two or more of these views side by side so the user can drag and drop between them. I know this can be done by having the view as an editor and have multiple versions of it that way, but the functionality lends itself to being more a view than an editor.
Investigate for R3.0. As we work to consolidate views as part of the scalability work (e.g. the generic Navigator, generic console, better use of the Properties view, etc), there will be more use cases where users want to see multiple instances of the same view at the same time.
I would find this highly useful if done well. Specifically, I like the solution used by MS DevStudio. There are controls above the vertical scrollbar and to the left of the horizontal scrollbar. These controls can be dragged to split the view into 2 or 4 panes within the same view. I have only seen this in editor views. I am not sure how useful it would be in, say, a breakpoint view. I've implemented a similar system in an editor I started on but never completed. I would be happy to donate my code to eclipse if you like this solution.
For views that allow specifying a sort order or filter, a simple splitter is not adequate since you may want different settings in both halves. Also, since views typically have less screen real-estate than an editor, splitting the view's area into two may be two confining.
Michael Scharf writes: In eclipse there can be at most one instance per view. This is a nice concept. However, there are use cases where this restriction can cause major headaches: - Suppose I want to launch two instances of a program and I want to see the console outputs side by side. At the moment, I have switch between the outputs (with the additional disadvantage that you loose the scroll position when switching) - Suppose I want to look at the hierarchy of two more classes. With the "at most one view" concept this becomes very difficult (again, switching between the states is slow and you loos the scroll position) - Suppose I have multiple debug sessions running and I want to see the local variables of two sessions side by side, that's not possible.... - ... any usecase where a user wants to see multiple views in parallel... We are implementing a set of views where one use case is, to have multiple instances visible at the same time (the examples above I used to illustrate the problem, and to show that this is a more general problem). - What is the eclipse way to solve those use cases? - Use (read-only) editors instead of views? - Create a plugins.xml with MyView1, MyView2, MyView3... all refering to the same class with different Ids? - Create view configurations on the fly, if needed (ist this possible)? Nick responds: Allowing multiple instances of the same view in the same perspective is something we have resisted in the past since we felt it would complicate the UI. However, in R3.0 we are trying to improve the scalability of the UI by reducing the number of duplicate or highly similar views (e.g. we're working on a generic navigator view and also a generic console view). This may exacerbate the limitation of one view instance, since there are times you want to see two facets of the same info simultaneously.
Other products have faked this out by declaring multiple occurrences of the same view in the plugin.xml, using different ids. The problem with this approach is that all the occurrences show up in the Show View > Other... dialog.
The fact that people are using the "fake it out with multiple ids" hack and are inventing their own frameworks for getting around this (like the generic console and new sync view) shows that this is a problem which needs to be fixed.
Was not able to address this for M5. M6 is a bug fix and performance pass. Marking for M7.
For M8 we are considering the following new API: /** * Shows the view identified by the given view ID and secondary ID in this * page and gives it focus. If there is a view identified by the given * view id and secondary ID already open in this page, it is given focus. * The given view name, if specified, is used instead of the name specified * in the view extension. * <p> * This allows multiple instances of a particular view to be created. * They are disambiguated using the secondary id. * </p> * * @param viewId * the id of the view extension to use * @param secondaryId * the secondary id to use, or <code>null</code> for no secondary id * @param viewNameOverride * the name to use instead of the view extension name, or * <code>null</code> to use the view extension name * @return the shown view * @exception PartInitException * if the view could not be initialized * * @since 3.0 */ public IViewPart showView(String viewId, String secondaryId, String viewNameOverride) throws PartInitException; and a similar variation on findViewReference (for more details, see 50094). This will allow plug-ins to programmatically open multiple instances of the same view (e.g. allow a view to clone itself). Since existing views may not be in a position to support multiple instances of themselves (e.g. might reasonably expect that page.findView(myId) returns itself), creating a view with a secondary id will only be allowed if the view extension specifies allowMultiple=true (a new attribute). There are no plans at the moment to allow multiple instances of arbitrary views to be opened by the end user.
can we have a superClass getter - getSecondaryId plus how will persisted views work?
Sorry, forgot to mention that IViewSite will have: /** * Returns the secondary id for this site's view, or <code>null</code> * if it has none. * * @return the secondary id or <code>null</code> * @see IWorkbenchPage#showView(String, String, String) */ public String getSecondaryId(); So you can obtain the secondary id using view.getViewSite().getSecondaryId(). View persistence will work as before, but with added support for persisting and restoring the secondary ids.
Released first cut of this. I've removed the viewNameOverride argument from showView to simplify the semantics (it would have no effect if the view was already showing. A view can always change its title if needed. Added the following API: IWorkbenchPage: IViewPart showView(String viewId, String secondaryId) IViewReference findViewReference(String viewId, String secondaryId) IViewSite: String getSecondaryId() IViewDescriptor: boolean getAllowMultiple() Limitations: - secondary instances are not properly persisted and restored across sessions
Can I programmatically control where the instances appear in the page? In fact in general - can I control where a view goes; apart from in the initial perspective setup (createInitialLayout)?
The perspectiveExtensions extension point lets you associate views and/or placeholders for views with specific perspectives, and allows you to specify relative placement of views, similar to what you can do with the initial perspective layout in code. See the doc for it, or grep through org.eclipse.jdt.ui's plugin.xml for examples.
I know how to do it statically in XML, the whole point of this bug is to allow dynamic view creation, so I cannot specify it in the XML. So can I control the placement programmatically? I.e I create a new view using showView(x,y) - where will it appear in the UI? Can I force it to go somewhere else? This gets more important now that I can have many instances of the same view (for editors we know where they go - into the single page wide editor stack so it was not an issue) but I really want to be able to reorg them for the user - or at least lay them out nicely. Window>Reset Perspective doesnt help to get the user out of a mess since the perspective definition doesnt know about the dynamically created views and I assume it will close them all (will it?)
Currently there is no way to programmatically specify where a new view will appear. Multi-instance views will appear in the same place as a view with the same primary id and no secondary id. i.e. it will use the same placeholder if there, or appear at bottom right. We could allow placeholders to specify both the primary and secondary id. e.g. primaryID="org.eclipse.ui.ResourceNavigator" and secondaryId="2" would be expressed as "org.eclipse.ui.ResourceNavigator/2". Reset Perspective will put you back to whatever the initial layout was. Note that it's possible for the initial layout to create multiple instances of the same view.
Basic support for multiple instances is in. Persistence to be addressed in M9.
Those of you interested in this bug will be interested in bug #56431. I have posted an updated patch to support "pattern matching" placeholders. This address issues with managing placement of multiple view instances. Please try it out if you have some free cycles and post your results. Thanks.
I am using 03.26 (M8) build. When I close the secondary view, the dispose method on the viewPart doesn't get called (It gets called when I close the primary view). Is it a known bug or are there any workarounds for the problem?
I am able to reproduce the bug mentioned in comment #18 with plugins from HEAD. More detailed steps to reproduce: 1) Show a view with id A. 2) Show a view with id A and secondary id B. 3) Close the view with with the secondary id and note that dispose is not called.
More info on the dispose problem: 1. When you close the primary view first and then the secondary view, the dispose gets called on the secondary view. 2. When you reset the perspective, the dispose doesn't get called on the secondary views.
Created attachment 9813 [details] patch to fix this bug ViewFactory has "hasView" method that only took a single Id. I added a second method to take a secondary Id and fixed up WorkbenchPage to use the right one. -m@
Patch released. The persistence bug has been fixed in one of the patches for bug 56431. The new pattern-matching placeholder support gives more control over where multi-view instances go. There is no plan to add further API here for 3.0. Marking as fixed. If there are further bugs or enhancement requests, please file separate reports.
*** Bug 50814 has been marked as a duplicate of this bug. ***
