Community
Participate
Working Groups
Created attachment 111683 [details] Path with fix. As part of investigating how to use the command framework to cleanup the clutter in debugger views I converted the JDT contributions to Debug, Variables, Expressions, and Breakpoints views to the command framework. The main functional difference is that when using commands, these menu and toolbar items can be hidden by turning off the "Java Debug" action set. I plan to make a similar contribution to CDT so that users of third-party debuggers would no longer be stuck with a bunch of meaningless icons in these views. On the implementation side, I had to create a ViewFilterManager which is managed by the plugin activator rather than by the actions as it is now. This is because the action handlers are not associated with any particular view. Although in retrospect I could probably still have added the filter registration to the handler in the IElementUpdater.updateElement() method, it really seems like a hack, where as the filter manager is more appropriately managed. Also, there is still some odd behavior if the user tries to use these commands before the JDI debug plugin is activated, where the checked state of the actions is not updated. This behavior was actually present when using actions as well, but with commands there is the option of making these items completely invisible, or disabled, until the plugin is activated.
BTW, I had to use an internal interface to implement some of these commands, but this should be addressed in 3.5.
I just came accross an older bug 176549, which was marked as "won't fix" because it relied on the debugging activity, so that the actions were available only when the JDT debugger was active. My patch uses the Java Debug action set instead, so it can be completely controlled by the user.
*** Bug 258984 has been marked as a duplicate of this bug. ***
A new concern for this bug may be stability issues found with toolbar UI when using the command framework.
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. -- The automated Eclipse Genie.
