Community
Participate
Working Groups
IWorkbenchPage#showActionSet(String) doesn't turn on the given action set if it's been previously disabled by the user. I didn't know this and had to debug through the implementation (not very far, fortunately :)) to figure out what was going on. I think the behavior is fine, but the JavaDoc should mention it.
I actually find this behaviour strange. Can you explain why you think it's OK?
I think it's OK in the sense that I can call this API as a client without having to worry about overriding the user's choice. For example, we (I) just released code that turns on the Debug action set when the Debug view is activated. This is a major help to users because it means they'll finally get their stepping hotkeys whenever they open the view. But without this behavior, we'd keep turning on the action set even if they really wanted it off. Ideally, I think there should be a boolean flag on the method, "force", that lets clients explicitly state whether or not they want this behavior.
Probably better for you to use the actionSetPartAssociations extension point. This allows you to associate an action set with a part (view or editor). If the user hides the action set, that is remembered by the workbench, and it will not be added back, e.g. if the user closes and reopens the view.
I don't think that extension point is really usable for us, unfortunately. From the actionSetPartAssociations schema: "In the case of a view, the action set will be visible when the view is the active part." We need the Debug action set turned on whenever there's a Debug view in the perspective, regardless of whether or not it's the "active part". Very often when debugging, the user has focus in the editor or some other view while they're stepping.
Assigning to component owner PW
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.
