Community
Participate
Working Groups
In 3.1, the notion of capabilities can be configured. However, the configuration is achieved internally by plugging in the preference page. As a consequence, any upstream client (e.g. Help) that must be capability-aware will be out of sync. In addition, since preference page is configured by the product (not the UI), there is no stable preference page ID so that preference dialog can be opened programmatically. This is very important issue that must be resolved in some way by M7, since it may require API of some sort.
Adding Mazen because Intro will have the similar problem if anything is provided by us (content pages will not, though, because they will be in sync with whatever the product has decided to call capabilities).
Dejan, Im not sure what Intro needs to investigate. Intro does not filter intro content by capabilities. so whats the concern/design issue from Intro's perspective?
If org.eclipse.ui.intro plug-in uses the word 'Capability' and 'Category' anywhere, it is in trouble. Otherwise, no work needed.
1) where would you be referring to the capabilities preference page anyway? That page is a kludge, and may not exist down the road. Plugins in the platform should not be directly opening the preference page directly. 2) presumably the upstream product developer that is overriding the strings could have the same ability to override the strings in help. There's no reason you couldn't implement our string-override pattern in help. My recommendation would be this: don't refer to capabilities. Don't refer to the preference page, and if you absolutely have to draw attention to the fact that certain help content is being filtered simply say it's being filtered... don't elaborate. :) Basically, for better or for worse, we've gone down the path where everything in the capability system is pluggable. All of the components are subject to change depending on the product, so you're trying to hit a moving target... I would recommend giving up the fight now. :)
I don't think it is that easy. The fundamental problem is that products claim that users may want to read documentation associated with disabled capabilites. We are asked to somehow mark these documents because it can be very confusing to read instructions that contain UI references that are currently filtered out from the UI. A logical next step would be to offer the link to the UI part that would allow users to change capability filtering state, and in SDK that is currently the Capabilities preference page. I would gladly stop chasing the moving target if UI provides an abstraction (API) that would allow me to show the UI artifact that handles capabilities. All I care is to direct users to this artifact - I don't need to know it is a preference page (e.g. openCapabilityEditor()). But I do need to know what is going to be modified in this UI part in advance because I need to formulate the message in a clear way. String override in help seem to me like an overkill. We don't have an existing extension point suitable for adding parameters like you did for the preference page. That means that we would need to define a new extension point just for capability string patterns.
Perhaps we can look into a general activity advisor for 3.2... I would be EXTREMELY leary of doing it at this point.
Providing some API to access the UI for working with capabilities might be an option, "if" there is a UI. The difficulty is that we don't know whether products will reveal this or not. Another way this could be done is to say something less specific like "consult your product supplier or documentation for more information".
Created attachment 20360 [details] for posterity, the help dialog
You can defer this defect for after 3.1 but don't close it.
Have I ever mentioned how much I love you? :)
No but it is good to know :-).
Will investigate a "configure capabilities" command for 3.4.
Anything happen with this? This bug is marked as critical. Given that it has been effectively reduced to an enhancement request, is that still valid?
No, we've not done anything about this - the silence has been deafening. Slapping a "configure capabilities" command in seems reasonable, however, it'd be an API change at this point. If I can have approval for that I'll investigate further.
Well now, how can I give a +1 until you've done enough investigation to prove that the fix is reasonable. ;-)
As it turns out, this is more complicated than simply adding a new command - we lack the same understanding that Dejan does with regard to which page to invoke to complete the command. This requires more thought... punting to 3.5.
Why is this marked critical?
Dejan, is this enhancement still relevant? It seems the discussion so far was around providing API "Capabilities enablement" dialog. While that might be a good thing on its own, it is a bit puzzling as to how it is going to help the Help system. As a user, I would prefer to have some indication on a help page that "this page is related to the disabled capability ABC" with a button to "enable capability ABC".
(In reply to comment #17) > Why is this marked critical? (In reply to comment #18) > Dejan, is this enhancement still relevant? No feedback received. Changing to enhancement for future consideration. If this is a critical bug you need to have fixed for 3.5 feel free to modify it.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
