Community
Participate
Working Groups
Here in Debugland, we would like to be able to close a view in a perspective other than the current one. I couldn't find any API to do this, but I noticed that the WorkbenchPage implementation has a private method to close a view given a Perspective (internal). A scenario where we need this is: 1. Starts a debug session in the Java perspective (opting not to go to the Debug perspective). 2. Some debug views are automatically opened when the program suspends. 3. Now go to the Debug (or any other) perspective. 4. Terminate the debugged program. 5. The views remain open in the Java perspective. We try to clean up views that were automatically opened when the user is finished debugging. But without a way to close a view in a non-active perspective, we end up leaving some views behind.
Is there some other trigger the Workbench could use, rather than having to provide explicit API? For example, if the view was introduced with a context change, shouldn't the workbench be responsible for maintaining that association and hiding the view when the context is revoked? It seems strange to me for Debug to have to manage the associations of workbench objects with contexts, and the meaning when contexts get introduced and revoked. Have we learned enough from the Debug scenarios to allow the Workbench to do this? Assigning to Kim since she's tracking the Debug context scenarios.
We've run into the need to do this for sticky views (Bug 57881) as well and we've found it's far more complicated than it would appear. Deferring for later.
Reopening for 3.1
This is also needed for dynamic view support. Currently when a plugin goes away we can only remove it from the currently active perspective.
*** Bug 97583 has been marked as a duplicate of this bug. ***
I think this is the one I've been looking for... (a newsgroup post found when searching for "close view" said search bugzilla). I think there is both a need for this and a bug in the current code (I'm on 3.0.1 right now). The need can be related to a UI where a logon is required to see content. Views show content, and when the user has logged off, regardless of the current perspective, the application would like to then close all views with data as part of the logoff process. Multiple instances (secondaryID) of the same view with different inputs may be active, and they all need to be closed at logoff as part of the cleanup processing. Application(plugin set) logic is attempting to do this. The plugin set is tracking view instances (this shows that the application knows of 3 secondary views it might want to close at logoff): view list size: 3 view: com.....ResultView@50275027 view: com.....ResultView@47f647f6 view: com.....ResultView@166c166c When a logoff occurs they attempt to hide all the secondary views and empty the primary view, but as many bugzilla hits seem to discuss, a hide is page specific, but really perspective in context, and the current perspective is implied. That would be fine if I could grab the perspectives where a view was visible and hide the view in each/every one. No joy there (yet). I can tell what views are open where (this shows two page/perspective sets, each with two views, one with secondary3/secondary4 and one with primary/secondary1): on page: Workspace - Resource -- page: org.eclipse.ui.internal.WorkbenchPage@35233523 Viewref: 3 :org.eclipse.ui.internal.ViewFactory$ViewReference@4af34af3 View: com.....ResultView@50275027 page: org.eclipse.ui.internal.WorkbenchPage@35233523 perspective: Resource org.eclipse.ui.internal.registry.PerspectiveDescriptor@e0f0e0f Viewref: 4 :org.eclipse.ui.internal.ViewFactory$ViewReference@46f846f8 View: com.....ResultView@47f647f6 page: org.eclipse.ui.internal.WorkbenchPage@35233523 perspective: Resource org.eclipse.ui.internal.registry.PerspectiveDescriptor@e0f0e0f on page: Workspace - MyPerspective -- page: org.eclipse.ui.internal.WorkbenchPage@35233523 Viewref: null :org.eclipse.ui.internal.ViewFactory$ViewReference@7fd07fd View: com.....ResultView@fbf0fbf page: org.eclipse.ui.internal.WorkbenchPage@35233523 perspective: MyPerspective org.eclipse.ui.internal.registry.PerspectiveDescriptor@6bfd6bfd Viewref: 1 :org.eclipse.ui.internal.ViewFactory$ViewReference@1dc01dc View: com.....ResultView@166c166c page: org.eclipse.ui.internal.WorkbenchPage@35233523 perspective: MyPerspective org.eclipse.ui.internal.registry.PerspectiveDescriptor@6bfd6bfd But when I get deep down into how the platform implements the logic for a hideView request it seems that it tries to do the right thing, but fails as the platform itself is confused... By trying to do the right thing and failing I mean that in the Perspective class things seem to go wrong. - WorkbenchPage.hideview calls WorkbenchPage.certifyPart; This asks if Perspective.containsView to as the Javadoc says "determine whether a view exists within the perspective". - This .containsView goes and uses .findView, but the find is not perspective specific as it calls Perspective.getViewReferences which finds views that are not part of the current perspective. Since all open views are in the viewRef array returned by .getViewReferences, the implication is that the view is part of the perspective. - A hideView continues but does nothing, and the view in another perspective is not hidden (which is the goal). The goal would be easier to reach with a viewRef.closeView option. I'm stuck now, unless of course there is a way to get to all perspectives with the view shown and ask it to be hidden such that all perspectives are checked. That processing path is what I'm still looking for... Its probably out there but maybe not API. The current "page almost = perspective" model may be part of the overall problem (not that I want to go back to different editors open on each perspective/page for a given window). I could have all view instances listen for the logoff event and hide themselves, but not sure that would work given their hideView would not be perspective specific either. That and I'm really hacking at someone else's code to try and allow it to be reused downstream, so I don't want to have to do all that much work :-). Anyway, view(pun-ha) this long ramble is a vote for this API request, but it should read as "API to close a view in any or all perspectives".
In addition we should look at the view API for hide/show and see if it is properly mirrored. Should I be able to close a view for every scenario I can open them?
we would like to add some views dynamically to an RCP Application and uninstall and update them on the fly. so i think this defect disables the possibiltiy to get rid of a plugin with a view ?
You're right, this will impact the unloading of plugin with a view that's visible (and fully realized) in multiple perspectives.
can we assume some eclipse version which is able to de-register everything correctly at least for eclipse extension points to be able to unload a plugin during runtime ?
Remy is now responsible for watching the [ViewMgmt] category.
