Community
Participate
Working Groups
1) The global debug toolbar in the Debug View is not shown when I start Eclipse the first time 2) The global debug toolbar vanishes after I restart Eclipse. I have to reenable it in the drop down menu after every start. 3) The the string in the drop down menu is incorrect: "Show DebugToobar" Version: 4.3.0 Build id: I20130516-2200 I think this bug was not in the M7 release but appeared later. BTW, I have installed the CDT plugin. But the CDT devs have told me that the toolbar is provided by the platform.
(In reply to comment #0) > I think this bug was not in the M7 release but appeared later. > > BTW, I have installed the CDT plugin. But the CDT devs have told me that the > toolbar is provided by the platform. I tested an older installation at home w/o CDT plugin Version: 4.3.0 Build id: I20130502-0800 Same behavior here for all 3 points.
The preference is stored in the LaunchView#partDeactivated method, which is not called during regular shutdown, but only when you put focus in the other editor/view. So, if you deactivate view before shutdown once the preference will be stored and the state will be persisted properly (kind of workaround). Paul, Is that correct behavior that partDeactivated is not called on shutdown? If yes then the fix in the Debug View will be easy.
Created attachment 232482 [details] Naive patch.
Created attachment 232483 [details] mylyn/context/zip
The patch fixes issues 2&3. 1 is rather expected since there is the global toolbar.
Eric, should our shutdown call partDeactivated/partClosed ? PW
We should match the behavior of 3.x in this respect, I'll punt this to Paul Elder since he's been looking into the various eventing issues... BTW, please don't apply the patch untilo we've looked into the behavior...
Created attachment 233472 [details] Patch - another approach Ok, I've for the purpose of investigation that the part should be notified about deactivation before closing, but the PartServiceImpl calls deactivation only once, in the "activate" method. So it looks like "deactivation" means that other view has been activated. In that light view disposal on shutdown does not mean "deactivation". What's more, the PartServiceImpl does not seem to even know that such operaton as closing a part can be invoked, so I've assumed it is not its responsibility. Given that, the best place to fix the issue seems to be WorkbenchPage#firePartClosed, which should firePartDeactivated as a first step.
Created attachment 233473 [details] mylyn/context/zip
I'd appreciate feedback as this is a relatively small patch for a bug affecting CDT users.
Krzysztof, this patch is restoring behavior that currently exists on the 3.x versions correct ? I'll add Paul Elder to the CC list since he's been looking into the eventing already...looks OK to me as long as 3.x sends the deactivated event on shutdown.
Eric, I've just downloaded 3.8.2 and checked how events are fired. It looks like a null view is activated on shutdown. I can only guess that setting null on shutdown was unnecessary overhead, so I think that my second patch properly adresses the problem. Thread [main] (Suspended (entry into method partDeactivated in LaunchView)) LaunchView.partDeactivated(IWorkbenchPartReference) line: 1432 PartListenerList2$4.run() line: 115 SafeRunner.run(ISafeRunnable) line: 42 Platform.run(ISafeRunnable) line: 857 PartListenerList2.fireEvent(SafeRunnable, IPartListener2, IWorkbenchPartReference, String) line: 55 PartListenerList2.firePartDeactivated(IWorkbenchPartReference) line: 113 PartService.firePartDeactivated(IWorkbenchPartReference) line: 242 PartService.setActivePart(IWorkbenchPartReference) line: 300 WorkbenchPagePartList.fireActivePartChanged(IWorkbenchPartReference, IWorkbenchPartReference) line: 57 WorkbenchPagePartList(PartList).setActivePart(IWorkbenchPartReference) line: 136 WorkbenchPage.setActivePart(IWorkbenchPart, boolean) line: 3649 WorkbenchPage.makeActive(IWorkbenchPartReference) line: 1331 WorkbenchPage.onDeactivate() line: 2737 WorkbenchWindow$28.run() line: 3016 BusyIndicator.showWhile(Display, Runnable) line: 70 WorkbenchWindow.setActivePage(IWorkbenchPage) line: 3011 WorkbenchWindow.closeAllPages() line: 882 WorkbenchWindow.hardClose() line: 1729 WorkbenchWindow.busyClose() line: 730 WorkbenchWindow.access$0(WorkbenchWindow) line: 715 WorkbenchWindow$6.run() line: 867 BusyIndicator.showWhile(Display, Runnable) line: 70 WorkbenchWindow.close() line: 865 WindowManager.close() line: 109 Workbench$18.run() line: 1114 SafeRunner.run(ISafeRunnable) line: 42 Workbench.busyClose(boolean) line: 1111 Workbench.access$15(Workbench, boolean) line: 1040 Workbench$25.run() line: 1284 BusyIndicator.showWhile(Display, Runnable) line: 70 Workbench.close(int, boolean) line: 1282 Workbench.close() line: 1254 WorkbenchWindow.busyClose() line: 727 WorkbenchWindow.access$0(WorkbenchWindow) line: 715 WorkbenchWindow$6.run() line: 867 BusyIndicator.showWhile(Display, Runnable) line: 70 WorkbenchWindow.close() line: 865 WorkbenchWindow(Window).handleShellCloseEvent() line: 741 Window$3.shellClosed(ShellEvent) line: 687 TypedListener.handleEvent(Event) line: 98 EventTable.sendEvent(Event) line: 84 Shell(Widget).sendEvent(Event) line: 1276 Shell(Widget).sendEvent(int, Event, boolean) line: 1300 Shell(Widget).sendEvent(int, Event) line: 1285 Shell.closeWidget() line: 617 Shell.gtk_delete_event(long, long) line: 1191 Shell(Widget).windowProc(long, long, long) line: 1765 Shell(Control).windowProc(long, long, long) line: 5116 Display.windowProc(long, long, long) line: 4377 OS._gtk_main_do_event(long) line: not available [native method] OS.gtk_main_do_event(long) line: 8317 Display.eventProc(long, long) line: 1193 OS._g_main_context_iteration(long, boolean) line: not available [native method] OS.g_main_context_iteration(long, boolean) line: 2342 Display.readAndDispatch() line: 3184 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2701 Workbench.runUI() line: 2665 Workbench.access$4(Workbench) line: 2499 Workbench$7.run() line: 679 Realm.runWithDefault(Realm, Runnable) line: 332 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 668 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 124 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 110 EclipseAppLauncher.start(Object) line: 79 EclipseStarter.run(Object) line: 353 EclipseStarter.run(String[], Runnable) line: 180 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 57 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 606 Main.invokeFramework(String[], URL[]) line: 629 Main.basicRun(String[]) line: 584 Main.run(String[]) line: 1438 Main.main(String[]) line: 1414
Thanks Krzysztof, that's good info. Have you tried to see if just setting the active part to null will work for us here as well ? The reason I ask is because as it currently is your patch does fix this issue but it's a bit of a hack since we're firing a partDeactivated event event though the part has *not* really been deactivated. What happens if you replace the current code with 'setActivePart(null)' ?
I'd like to, but I can't find a right place to do it. PartServiceImpl seems to be unaware of the close event, so I thought maybe WorkbenchPage#close would be a nice place, but then I've noticed that WorkbenchPage#activate is null guarded. The only place which seems to be suitable enough is WorkbenchPage#hidePart. The hide event is currently broadcasted (which is not a big difference from my last patch). The point is that E4 WorkbenchPage#close seems to rather hide parts instead of closing them: for (MPart part : partService.getParts()) { // no save, no confirm, force hidePart(part, false, true, true); } I'm afraid that without knowing the idea behind the current code it will be very difficult to come with a better patch :(.
I have confirmed that 3.x does fire partDeactived on the active part during workbench page shutdown.... But, calling firePartDeactivated from firePartClosed is definitely the wrong place. It has two undesirable effects: 1) it fires partDeactivated on parts that were not active 2) it fires partDeactivated out of sequence. The desired sequence (at shutdown) is: partDeactivated, partHidden, partClosed I think a better place to initiate a call to firePartDeactivated would be in CompatibilityPart.widgetSetHandler, immediately before the firePartHidden() call. However, there would need to be some necessary testing to ensure that the part is still marked as the active part. (A part being closed 'should' have partDeactived called on it already by the part service.) I have pushed the following patch to Gerrit that does this. I believe this satisfies all the above goals (and addresses the problem with the Debug view). Let me know. https://git.eclipse.org/r/14614
Since this will be a Platform UI-only fix I am moving the bug there
I took the liberty and released the patch.
