Community
Participate
Working Groups
I checked out org.eclipse.jface, org.eclipse.ui, and org.eclipse.ui.workbench from HEAD in order to pick up a new API that was added to the workbench. But in my testing, I'm not getting any partClosed() notifications. By debugging, I've verified that my part listener is being registered with the active workbench page. I've got an existing bug report open for the fact that *some* part notifications haven't been getting sent (bug 50171), but now I'm not getting any.
Nick Edgar wrote: It's not a bug. It's just that the part is hidden - it hasn't been closed, so there wouldn't be any close notification. Jared replied: "Hidden" in the API means "obscured". partHidden() notifications are sent whenever a view is covered by another view. If closing a part doesn't send a partClosed() notification, what notification is sent? Nick responds: OK, so "hidden" wasn't quite the correct term. Hidden/visible notifications are intended to handle obscuring, as you describe, not view open/close. For further terminological confusion, note the IWorkbenchPage.hideView() is equivalent to manually closing it. It is, however, symmetrical with showView (), both in name and function. The semantics of partClosed have been complicated by the sharing of views across perspectives (introduced in Eclipse 2.0). Note that IPartListener[2] is registered on IPartService via IWorkbenchPage, not the perspective. So it currently only notifies when the part has been closed from all perspectives in the page. That is, you'll only get a partClosed() notification when the part itself is being disposed. There are no notifications currently to say "this part has been closed in this perspective" or "this part has been closed in the active perspective". It's too risky to change the behaviour of partClosed() now. Existing listeners may care more about the lifecycle of the part itself rather than whether it's open in the current perspective. We may be able to add new lifecycle methods, e.g. partClosed (IPerspectiveDescriptor, IWorkbenchPartReference) or partClosedInCurrentPerspective(IWorkbenchPartReference). Unfortunately, it would be very difficult to make this happen 3.0 at this point though. It would help to know a bit more about what you're trying to do and what you really need to know. You might be able to get by for now with tracking partHidden, then seeing if the view is still there using IWorkbenchPage.findViewReference(String). Note that this -does- limit itself to the current perspective. And, yes, I acknowledge that this is inconsistent with the notifications. Just for the record, here are the notifications you currently get when closing a Navigator that is shared between the Java and Resource perspectives. It's being closed from the Java perspective. Clearly there are some inefficiencies here. The Hierarchy should not be getting materialized and the TextEditor should not be getting activated. partDeactivated(Navigator) partActivated(TextEditor) partHidden(Navigator) partOpened(Hierarchy) partVisible(Hierarchy) partHidden(Hierarchy) partDeactivated(TextEditor) partActivated(PackageExplorer) And here are the notifications you currently get when you close the last occurrence of it from the Resource perspective: partDeactivated(Navigator) partActivated(TextEditor) partHidden(Navigator) partClosed(Navigator)
My concern here stems from our automatic view opening/closing in the Debug perspective. I register a listener for partClosed/partOpened because I want to know when the user closes or opens a view. The reason being that once the user's manually closed/opened a "managed" view, we won't open/close that view again. If we can't accurately track this, it means that the user will end up wrestling with the debugger. There might be some other way for us to manage this, but nothing's come to mind yet. DarinW may disagree, but if we can't prevent the feature from overriding the user's choices, I'd consider our context management story unshippable.
Can youi try hooking partHidden and testing whether it's still in the perspective via findView?
The JavaDoc on IPartListener(2) should really be beefed up to explain when the various notifications are sent. I never would have guessed that the listeners behave the way they do by reading the doc. I poked around a bit, though, and it looks like IPerspectiveListeners are sent a partHidden notification when a view is closed (but not when they're "hidden"). The fact that partHidden notifications aren't sent when views are hidden is probably a bug, but in this case it works to our advantage. To make these notifications consistent with the part notifications, I'd suggest that partHidden should be sent when a view is obscured and a new event, partClosed, should be sent when a part is closed within a perspective.
Not sure I was clear in my last paragraph (I should really proof-read my comments *before* I submit them :) ). CHANGE_VIEW_HIDE perspective events are currently fired at the "right time" for our purposes. But for consistency in the API's terminology, I'd suggest making CHANGE_VIEW_HIDE be sent when views are "obscured" and adding a new CHANGE_VIEW_CLOSED event that is sent when a view is closed within a perspective.
You'd probably also want to be told -which- part too.
Whoops! Scratch the perspective listener idea, then. Your suggestion about listening to partHidden notifications and using findView should work.
It looks like partOpen notifications aren't sent when you open a part either (if it's open elsewhere). :( Is there a similar workaround I'm not thinking of? Do you think there's any chance of adding a new listener for 3.0? Not a breaking API change, but an addition. Something like IPerspectiveListener2, which adds the part notifications?
Can you use IPartListener2.partVisible then check if it's newly opened using page.findView? You'd have to check findView before registering the listener to detect whether it was initially opened or closed in the perspective. If these workarounds don't work for you, we can look add adding new API early in M9.
*** Bug 50171 has been marked as a duplicate of this bug. ***
Jared, please let us know whether any action is needed here.
Well, we need to know when views are opened and closed in the intuitive sense, not just the first time a view is opened in a window or the last time it's closed. Your workarounds might work (though I suspect that the partOpen workaround would be buggy), but I really feel that the workbench should be sending notifications in this case. It doesn't seem right that clients should have to keep track of the views themselves in order to figure out when they're being opened and closed. The workbench should take care of that for us.
Will investigate for M9.
It looks like the unspec'ed behavior of IWorkbenchPage#findView has changed such that the workaround we're using for partClosed() is no longer working. As suggested, we're currently listening to partHidden() and then calling findView() to see if the view has actually been closed. IWorkbenchPage#findView() used to return null if the view wasn't open in the current perspective. But now I get a non-null value when I call findView(...) in the viewHidden() callback when a view is "closed" (really closed, not just closed for the last time). This workaround failure was reported as Bug 58591 in the debugger.
*** Bug 58591 has been marked as a duplicate of this bug. ***
I've filed Bug 60039 to track the failure of the workaround. This new bug is a major problem for the debugger.
While looking at bug 60039 (fixed), I noticed that LaunchViewContextListener often calls getActiveWorkbenchWindow and getActivePage. I'm not sure exactly what this class does, but it seems to me that if the intent is to track visibility of other views in the same perspective as the Launch view, then it should just use the Launch view's page. I did encounter one instance where it appeared to get confused by me having two windows open (it was talking to a different window than the one containing its Launch view). In Eclipse >= 2.0, there is only ever one page per window, but the page may contain multiple perspectives. Can the calls to getActiveWorkbenchWindow and getActivePage() be eliminated?
Good question. I filed bug 60327 against Platform-Debug to look into this problem.
Sorry, we'll have to live with the workarounds for 3.0. Will consider new lifecycle API for 3.1.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
