Community
Participate
Working Groups
We need to hook our new Eclipse 4 code into the existing Activities mechanism.
Cross-referencing uses of the WorkbenchActivityHelper#filterItem method between R3_development and R4_developement shows the following ('OK' means that the call is in both branches): org.eclipse.ui.actions BaseNewWizardMenu OK PerspectiveMenu OK org.eclipse.ui.actions NewWizardMenu OK org.eclipse.ui.activities WorkbenchActivityHelper OK org.eclipse.ui.internal FolderLayout PageLayout ShowViewMenu OK org.eclipse.ui.internal.actions AbstractWorkingSetPulldownDelegate OK org.eclipse.ui.internal.activities.ws ActivityViewerFilter OK org.eclipse.ui.internal.dialogs CapabilityFilter OK CustomizePerspectiveDialog FilteredPreferenceDialog OK NewWizardNewPage OK ViewContentProvider OK WizardActivityFilter OK WorkbenchPreferenceDialog OK org.eclipse.ui.internal.navigator.wizards CommonWizardDescriptorManager OK org.eclipse.ui.internal.quickaccess PerspectiveProvider PreferenceProvider ViewProvider WizardProvider org.eclipse.ui.internal.registry EditorRegistry OK org.eclipse.ui.navigator CommonActionProvider OK MavigatorActionService OK org.eclipse.ui.tests.activities UtilTest OK
So it appears that in 4.x we need to hook in the 'filterItem' calls in the following locations: ModeledPageLayout (addView adds a view placeholder (TBR == false) if the item is filtered. The PageLayout changes affect the Fast View management which is unsupported in 4.x. CustomizePerspectiveDialog We also need to hook it into the 'Search' logic in the same way that it was hooked into quick access...
Hmmm, I don't see any place where the command infrastructure filters (even in 3.x) so perhaps I'm missing something... Paul, do you know where I can find the capabilities filtering code in 3.x ?
(In reply to comment #3) > Hmmm, I don't see any place where the command infrastructure filters (even in > 3.x) so perhaps I'm missing something... > > Paul, do you know where I can find the capabilities filtering code in 3.x ? Commands themselves are not filtered by activities. The Keys preference page *is* supposed to (the old one appears to be), but the current one does not (in both 4.x and 3.x). In 3.x, the WorkbenchMenuService applies activities to any menu or tool items we create (probably merges activities with the visibleWhen clauses). PW
M2 is done...
Created attachment 204313 [details] Hook capabilities in to missing areas This patch hooks capabilities back into all the areas listed in this defect EXCEPT the CustomizePerspectiveDialog. Currently in e4 CustomizePerspectiveDialog is gone. Hacked out during the split. Adding it back is talked about in Bug 320478. I suggest that if this patch is acceptable, then this defect is closed and the capabilities work in respect to customizing perspectives will be part of 320478.
Sounds good to me. Dean, could you come by on Monday and we'll go over this one together, I'll need help understanding where they're used...
Pushed in >20111003. commit 126b6e1fcd335c629519d8cc2d7a80245bfa8d97 Dean, please check to see if there are other places where we were doing activity filtering that uses API other than 'finterItem'...
The o.e.ui.menus code in 3.x also uses activities. Is there a different bug to handle integration of activities into menus/toolbar visibility? PW
Couldn't find one....there is now, bug 359778. Paul, there are a number of different API's (various collection filters...) in the WorkbenchActivityHelper, do you know if any of them are used outside of the commands code ?
Scanned all references to all public methods in WorkbenchActivityHelper and compared their use in 3.8 to 4.2. Many of the diffs are in org.eclipse.ui.tests.activities.UtilTest. Is the intent that all the 3.8 ui tests pass in 4.2? The majority of the other uses of the WorkbnechActivityHelper API, would be easy to implement in 4.2 but hard to find valid test cases to see if the changes have any effect. In most cases that I found in 3.8 the effect of the additional API changes are masked by filtering already done in the code paths by the filterItem call. One illustrative example, is the use of restrictUseOf by ViewRegistry.find(). This is only called by the SavePerspectiveDialog, to filter contents as the user types a name. However, the list it is trying to filter has already been called by the PerspectiveProvider. So the question is, should we just go ahead and add the call to these methods back to reflect 3.8 or do we wait until actual differences are found and reported? In any event, here are the list of the differences. createUnifiedId() Called by: LayoutHelper.addViewActivator() When a capability is activated the active perspective should show the new views immediately. getDisabledCategories() org.eclipse.ui.tests.activities.UtilTest getEnabledCategories(IActivityManager, String) org.eclipse.ui.tests.activities.UtilTest getEnabledCategoriesForActivity(IActivityManager, String) org.eclipse.ui.tests.activities.UtilTest isEnabled() org.eclipse.ui.tests.activities.UtilTest restrictCollection(Collection, Collection) PerspectiveRegistry.getPerspectives() Controls what is shown in General new project wizard. ViewRegistry.getStickyViews() Not sure this is even used in e4 ViewRegistry.getViews() Only used by ParameterizedCommands. Easy to put the code back but not sure how to test it. ViewRegistry.ViewCategoryProxy.getViews This inner class has been replaced by ViewCategory in e4. Adding the filter code is simple, but again, not sure how to test it. View category behaviour appers to be the same between 3.8 and e4 without the changes copied over restrictUseOf(Object) PageLayout.createView() I believe this is fixed in ModelPageLayout.addView() by the first patch in bugzilla 204313 PerspectiveRegistry.findPerspectiveWithId(String) Again, easy to test … hard time finding a test case that would expose it. In many cases, the filtering done by this method has already been done by the various providers. PerspectiveRegistry.findPerspectiveWithLabel(String) This one is clearly only called by the SavePerspectiveDialog … however, not particularly necessary as the list is already filtered ViewRegistry.find(String) Same org.eclipse.ui.tests.activities.UtilTest
(In reply to comment #10) > Paul, there are a number of different API's (various collection filters...) in > the WorkbenchActivityHelper, do you know if any of them are used outside of the > commands code ? The one I'm thinking of in 3.x is in WorkbenchMenuService. ContributionItemUpdater gets an IIdentifier for individual IContributionItems, and then adds itself as an IIdentifierListener. It combines any visibleWhen that applies to that ICI and any activity state as well. PW
(In reply to comment #11) > One illustrative example, is the use of restrictUseOf by ViewRegistry.find(). > This is only called by the SavePerspectiveDialog, to filter contents as the > user types a name. However, the list it is trying to filter has already been > called by the PerspectiveProvider. filterItem and restrictUseOf provide slightly different semantics. restrictUseOf(*) uses activities with enabledWhen core expressions in a special way. It's used to make things like views completely unavailable from the View Registry in 3.x. ex: a regular disabled activity can make a view disappear and adds the "Show All Views" checkbox at the bottom of the Show View Dialog. An expression-based activity will make the view disappear and doesn't add the checkbox to the Show View Dialog. PW
(In reply to comment #11) > Many of the diffs are in org.eclipse.ui.tests.activities.UtilTest. Is the > intent that all the 3.8 ui tests pass in 4.2? Yes, unless there is a reason to deviate. > So the question is, should we just go ahead and add the call to these methods > back to reflect 3.8 or do we wait until actual differences are found and > reported? For myself, I'd say just add them and then we can take them out later if it causes a problem. Activities and capabilities are a hot item so I feel like they should at least be (somewhat) working before the general community consumes it.
Created attachment 205320 [details] Fixes described in Comment #11 Added a patch for the 2nd round of fixes described in Comment #11. There are two file changes that may appear to be gratuitous, but they are not. WorkbenchActivityHelper.restrictCollection(). Added some typing to collection parameters. Not an attempt to clean up warnings in this file, but required to prevent adding new warnings to callers I was adding as part of this patch. Removal of method ModeledPlaceHolderLayout.isVisible(). Adding new logic to ModeledFolderLayout as part of the patch revealed that this method should not be called and thus, not needed. I believe this patch marks the end of the non-command (menu) related capabilities work. I think this defect could be closed after this patch is committed. Note that the menu work still needs to be done. As well as Customize Perspective dialog work (which has a patch attached to it already ... but it is old)
(In reply to comment #15) > Created attachment 205320 [details] > Fixes described in Comment #11 I've released the changes related to the perspective registry to R4_development. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_development&id=f7653986b00e3bda6aa50774168d84c613bd276a As the patch is pretty big, I want to release the changes in phases.
(In reply to comment #15) > Created attachment 205320 [details] > Fixes described in Comment #11 If a view is targeted by an activity with an expression which evaluates to 'false' and the activity is contained within a category grouping, the view will show up in the quick access list even though it shouldn't be.
(In reply to comment #15) > Created attachment 205320 [details] > Fixes described in Comment #11 1. Define a category and an activity in that category that filters a perspective. 2. Force the perspective to be opened (which will in turn activate that capability). 3. Turn off the capability. 4. Shutdown. 5. Add an expression that evaluates to the 'false' to the activity that's filtering the perspective. 6. Restart Eclipse. 7. The perspective no longer has an icon. In 3.x it will fallback to a default icon. Bug 360685 is also related. I wouldn't really consider this to be a huge problem so it may be better to use a new defect to track this item.
Created attachment 205457 [details] Screenshot depicting the state in question. (In reply to comment #15) > Created attachment 205320 [details] > Fixes described in Comment #11 If you contribute a view that's filtered by an activity to a perspective as a new stack (instead of inserting it into a stack of one of the perspective's existing views), you will see empty space in that area. Both activating the capability and showing the view manually does not cause the view to become rendered.
(In reply to comment #19) > If you contribute a view that's filtered by an activity to a perspective as a > new stack This is incorrect. The view should be contributed as a _standalone_ view.
(In reply to comment #19) > you will see empty space in that area. Both activating the > capability and showing the view manually does not cause the view to become > rendered. This is also incorrect. The space is empty because my view's implementation just makes a composite. The bug is that the standalone view is visible even when the capability is off.
Created attachment 205569 [details] Fixes for comments 17, 18 and 19 Here are patches to fix the problems described in comments 17, 19 and 19. This patch must be applied on top of the patch "Fixes described in Comment #11" Note that once applied the stand alone view will be hidden when it is filtered out, however, due to bug 361460 the view will not become visible when the capability is enabled. For now, after enabling the capability reset the Java Perspective to see the view displayed. If this patch is accepted it might be time to close this defect and open new defects for any outstanding problems that might be found.
I've pushed the necessary changes to fix comment 17 to R4_development. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_development&id=ba20d05731c7e31d4909888f4885a0a351dd090a
Pushed the changes for comment 18's bug. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_development&id=f16d6c4775e91caa31b7a6a3b4f9453ab960a9d0
I've pushed the final changes to R4_development. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_development&id=22e84694f3f452ad215d941388bbd1628e768024 We will open new defects for other problems we encounter. Thanks for your help, Dean!
