Community
Participate
Working Groups
Trigger point should be defined in XML. When code that implements a trigger point is used it should access a central source in workbench to see if the trigger point should be honoured. In this way products can define policy for trigger points (ie: disable the import/export wizard from being a trigger point).
Schema files for trigger points have been checked in. (org.eclipse.ui/schema/activitySupport.exsd). Implementation forthcoming.
Nick, I have RCP concerns regarding this bug. What should be the default behaviour of a trigger point in an RCP app? Should they get the prompting dialog that's currently present in the workbench for free? The alternative is that they get a basic advisor that just enables activities without prompting.
I think the default prompting behaviour would be fine, as long as the app can override it. Matt, do you have any concerns here?
Current RCP apps will get the dialog so perhaps it's best for us to keep using it if only for that reason.
Initial implementation in head. Included is support for custom TriggerPoint advisors. The default for workbench is essentially what we have now (the dialog). The provided implementation for the SDK is similar, except that the strings have been tweaked such that "Activities" are "Capabilities". Trigger point definitions themselves are currently ignore. The next step is to implement the trigger point registry and map out our existing trigger points.
Trigger point definitions for workbench and IDE have been created along with the trigger point registry code.
Verified in I20050330-0500
