Community
Participate
Working Groups
Activity pattern bindings should be more like this: <extension point="org.eclipse.ui.activities"> <activity name="FooBar" description="" id="foobar"> </activity> <activityPatternBinding activityId="foobar"> <or> <includePattern="org\.foo\.bar.*"/> <excludePattern="org\.foo\.bar\.ui\.test/.*"/> </or> <activation> <or> <includePattern="org\.foo\.bar\.ui/A"/> <includePattern="org\.foo\.bar\.ui/B"/> <includePattern="org\.foo\.bar\.ui/C"/> </or> </activation> <activityPatterBinding/> </extension> In this example, I want bind all the foobar related components to the foobar activity, except for a few activation points (the A, B and C) , and the test plugin. In the current activities implementation, in order to do this I would need to create several pattern bindings that would work around A, B and C and test. You could argue that I should rename my IDs so they would work better with regular expressions, but this is not always an option because sometimes code heavily depends on these IDs; also many times I may not have access to the code (e.g. if I want to define my own java activity rather than using the one that comes with eclipse). So, once I define my activities to include everything but the activation points, there is still the issue of making A, B, and C and actually trigger foobar. Currently I need to do this in java code. This is a problem, especially if different product offerings (each with some of the same plugins) wish for a different flavor of activities. Now, instead of simpling switching activities plugins, we need to code to multiple activity sets to trigger the activations. Also, there is no way to do this unless I own the code for A, B, C. The above definition specifies that A, B, C and test are activation points for foobar. This will automatically exclude A, B, and C from being filtered by the UI (so they are always visible). Also, if a user stumbles upon A, B, or C, then foobar will automatically be enabled. If another product comes along and wants to split foobar into foorbar1 and foobar2 and use A to activate foobar1 and B to activate foobar2, and always filter C, then no java code would need to be touched. The current design makes this impossible.
I agree we need to expand upon how the user may define bindings - we originally had the notion of exclusion bindings but they were dropped for reasons that I can no longer recall. I wish they had remained. Given what you propose, there is still the requrirement of code that uses the activation points. I'm not sure how these additions would alleviate this need. Can you give further explanation?
This isn't going to happen for 3.1... deferring.
Retrofitting something like this into the existing API would be prohibitively expensive. Marking as WONTFIX unless you have have a valid case that can't currently be modeled with exiting APIs (irregardless of difficulty or verbosity).
