Community
Participate
Working Groups
We added an option to show the standard debugging actions in the top level toolbar, and hide them in the Debug view (bug 258767). However other debuggers that contribute actions to the debug view toolbar also would like to control their visibility. We are currently using the org.eclipse.debug.ui.debugViewToolbarVisible system property to indicate toolbar visibility. However, there is no listener API available for system properties so actions that use it do not update their visibility correctly. In addition to the system property, I want to add a property tester which will check the system property. Clients can use the property tester and be updated when the property is changed by the launch view's toggle action. I.e. toggle action will call IEvaluationService.requestEvaluation() after toggling toolbar visibility.
Created attachment 215109 [details] Patch with fix.
Created attachment 215113 [details] Updted patch with comments.
I'd like to target this for 3.8 still, since the reverse stepping toolbar is quite broken in CDT without it. It is technically an API change though, so I think we'll also need PMC approval. Mike, could you have a quick look?
(In reply to comment #0) > However other debuggers that contribute actions to the debug view toolbar > also would like to control their visibility. What is the impact for them if we don't fix this bug? Will their actions appear in the Debug view's local toolbar even though it's hidden (which is the case out of the box)? I'm not sure a new property tester is the right API here.
(In reply to comment #4) > What is the impact for them if we don't fix this bug? Will their actions appear > in the Debug view's local toolbar even though it's hidden (which is the case > out of the box)? The bug appears only when toggling toolbar on/off, where the toggle doesn't take effect until some other user action (e.g. selection change) forces the actions' visibility to be udpated. Marc indicated in bug 372032 comment #14 that it's not a severe bug, so I'm OK to post-pone this. > I'm not sure a new property tester is the right API here. Me neither. Come to think of it, it would be better if the call to IEvaluationService.requestEvaluation() could also be used to evaluate system properties.
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. If the bug is still relevant, please remove the stalebug whiteboard tag.
