Community
Participate
Working Groups
If you open a Java editor in one workbench window, all other workbench windows will have its contributions show up such as a 'Refactor' menu or tool bar contributions like the breadcrumbs feature.
1. Activate the 'Outline' view. 2. Window > New Window 3. Activate the 'Outline' view. 4. Go back to the first window. 5. Activate the 'Package Explorer' view. 6. Notice that second window now also shows the 'Source' and 'Refactor' menus.
I believe this is an effect of our earlier attempt to push variables to the application context. Really, we should make sure when our code is evaluating information, it uses takes the model context and uses context.getActiveLeaf(). This is something I feel we should review for 4.1.1 and if the cost is low, include it. PW
When contexts get activated, their string ids are pushed into the application's context (refer to ContextContextService's activateContext(String)). Since it's in the application's context, the new workbench window ends up retrieving these ids makes the editor action sets visible to the user.
What we want: contexts are set at each level as they are activated. The activeIds are the Set of activeIds found by askingContext.getActiveLeaf() and then summing them up
Fix pushed to R4_development. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_development&id=c21ab3481f6463d26c86c9fb88f51279a83ac968 Technically speaking, the contributions appear in the second workbench window for a few seconds before they get removed.
This is broken again as of M20110817-2001. Since this is not a critical problem that affects the use of the SDK, I will not try to investigate a fix for 4.1.1 GA.
(In reply to comment #4) > What we want: contexts are set at each level as they are activated. The > activeIds are the Set of activeIds found by askingContext.getActiveLeaf() and > then summing them up The problem here is that this process always adds up to the application's context. This means even for something being evaluated in an inactive workbench window, it will take active contexts from the application. Since there is only one context service at the application level that activates and deactivates contexts, an inactive workbench window will seem as if it is actually active.
I see this flickering very often: I normally have perspectives in separate windows, and clicking in the stack of the debugger causes continual flicker in other windows.
Inserting an additional layer of IContextServices at the window level with a SlaveContextService doesn't seem to fix this problem. I feel like we need a separate EContextService at every level to locally store what contexts should be active at any given position. I think ActiveContextsFunction may also need to be changed. As described by comment 7, we always recurse upwards regardless of whether we're the active child or not, so even inactive windows will be affected by the active context chain of the currently active window.
Created attachment 207499 [details] WorkbenchWindow patch v1 Each window already has its own EContextService implementation. They don't have an IContextService implementation though. So if we create a new one for it then it'll have its personal IContextService instead of returning the one for the application.
(In reply to comment #10) > Created attachment 207499 [details] > WorkbenchWindow patch v1 Bug 364757 has surfaced itself now that the system is actually working as intended.
Fix released to master. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ec87e24a07c23cb6144b4cdb77bd3303b7530171
Verified with I20111205-2330 on Windows 7. Brian, please let me know if you spot any problems.
No problems from me — it's been great. Thanks Remy.
