Community
Participate
Working Groups
Thread [main] (Suspended (breakpoint at line 1824 in Shell)) Shell.setVisible(boolean) line: 1824 TrimStack.showStack(boolean) line: 339 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 79 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 618 MethodRequestor.execute() line: 42 InjectorImpl.invokeUsingClass(Object, Class<?>, Class<Annotation>, Object, PrimaryObjectSupplier, boolean) line: 178 InjectorImpl.invoke(Object, Class<Annotation>, PrimaryObjectSupplier) line: 152 ContextInjectionFactory.invoke(Object, Class<Annotation>, IEclipseContext) line: 86 ModelServiceImpl.bringToTop(MWindow, MUIElement) line: 201 ModelServiceImpl.bringToTop(MWindow, MUIElement) line: 220 PartServiceImpl.activate(MPart) line: 357 StackRenderer(AbstractPartRenderer).activate(MPart) line: 105 StackRenderer$ActivationJob.run() line: 89 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 134 Display.runAsyncMessages(boolean) line: 4041
We need some API in the PartService that would force it to choose a new part *within the 'presentation' to become active. By 'persentation' here I really mean a top-level window or one of its 'detached' windows (i.e. in either an MWindow or MPerspective's list of windows, explicitly avoiding minimized stacks. I'm not sure how the current 3.x code handles this except I know that it uses the 'activationHistory' to track down likely candidates... Perhaps we should enhance the 'find' code to take some (fairly limited for now) set of options.
In 3.x, a view in the stack that's being minimized actually gets activated (setFocus() is called) before the original view becomes the active view again (setFocus() is called for the original view).
The real question is what happens when the FastViewPane gets torn down...in 3.x when this happens the active part always becomes a part within the 'main' presentation; the FVP going away will never result in another one being opened even if, for example, the previously active part was also in a minimized stack.
Marking for a look in RC1.
Win7, Build id: I20100718-2237 1. Open a file. 2. Detach the 'Outline' view. 3. Bring it back to the right of the editor. 4. Minimize the 'Outline' view. At this point the icon goes to the trim but the view also floats above the editor as a fast view. I believe this is what Remy originally was describing in this bug, but I wasn't sure...
(In reply to comment #5) > I believe this is what Remy originally was describing in this bug, but I wasn't > sure... Yes, that is what I'm talking about. Not really a huge deal to me but then my bar is pretty low.
(In reply to comment #6) > (In reply to comment #5) > > I believe this is what Remy originally was describing in this bug, but I wasn't > > sure... > > Yes, that is what I'm talking about. Not really a huge deal to me but then my > bar is pretty low. Yes, I don't see this as a huge thing, except that strange things happened when I tried to close the view. See bug 320321.
This problem still exists even with the fix for bug 320243. It's marked RC3, but I don't think this one is critical given that bug 320321 is now fixed.
+1 thanks
Removing outdated target milestone.
Currently working in Kepler (and likely Juno as well).
