Community
Participate
Working Groups
Build Identifier: I20100608-0911 CDT 7.0 In Variables View, its context menu items "Add Global Variables", "Remove Selected Global Variables" and "Remove All Global Variables" and the same local toolbar buttons are always disabled if the underlying debug engine is not CDI models. This is because the org.eclipse.cdt.debug.ui plugin.xml has two extension contributions 'org.eclipse.debug.ui.variablesView.popupMenu' and 'org.eclipse.debug.ui.variablesView.toolbar' that makes the buttons and context menu items always visibel and control only enablement. This make end-users of dsf and other cdt-non-cdi debug models confused. Reproducible: Always Steps to Reproduce: 1.Do a c project with dsf debug. 2. Open variables view. 3. The view's context menu items and local toolbar buttons for those three global variable actions are always disabled.
See http://old.nabble.com/Cannot-add-Global-variables-in-DSF-debug-session-td23314984.html for history. There is a comment of RE: Cannot add Global variables in DSF debug session by Marc Khouzam :: Rate this Message: Reply | View Threaded | Show Only this Message > > Marc, > > Should we make the "Add Globals" action visible only for CDI models? > It is always grayed-out for DSF-GDB right now. But you are right, if it was invisible, that would be even better.
Created attachment 189557 [details] patch for this item The patch makes the global variables related context menu items and local toolbar buttons of variables view invisible when debug model does not support global variables. In this patch, I use org.eclipse.ui.menus' menu contribution and comment out the legacy viewer contribution and view contribution. A new property tester is added to test the visibility of those new menu/toolbar items. Also, commands are defined and default handlers are provided. I expect that future clients may provide specific handlers when there is a need. Once the menu/toolbar items are enabled, the user experience is same as old action handlers. Please review this patch and let me know if you have any concern. We would like this patch to be included in 3.7 M6. Thanks.
I have tried this patch. It seems to be fine, but the problem is that the command framework doesn't work very well with toolbars. Sometimes the toolbar is not updated and the actions are not visible when they are supposed to be visible and vice versa. Extra click is required to force the update. It's a bug in the platform, I remember seeing it in Eclipse 3.5 and it hasn't been fixed since. Have you seen this in your implementation? The alternative is an action set for these actions which can be disabled by default.
(In reply to comment #3) > I have tried this patch. It seems to be fine, but the problem is that the > command framework doesn't work very well with toolbars. Sometimes the toolbar > is not updated and the actions are not visible when they are supposed to be > visible and vice versa. Extra click is required to force the update. I had trouble getting reverse debugging commands to appear/disappear properly with the toolbar, but eventually it worked well (or at least it seems). It is actually Toni that got it to work. Maybe something can be done with this patch to fix it? See 290572 for some details.
(In reply to comment #4) I meant: see Bug 290572 for some details.
using the command framework will fail for multiple view instances, the command handler is shared globally, hence all views will show the same state regardless of the selection in each view. I raised the toolbar issue to platform a while ago and it won't be fixed until E4.
(In reply to comment #6) > using the command framework will fail for multiple view instances, the command > handler is shared globally, hence all views will show the same state regardless > of the selection in each view. > > I raised the toolbar issue to platform a while ago and it won't be fixed until > E4. Is adding the action set a better solution?
The short answer is yes. This is my understanding of the down side of the menu extension point. For toolbar actions and main menu (top level) actions, it is better to use action set. You can get away with the menu extension point for context menu and drop down menu, where the action state is query before it is draw.
Created attachment 190870 [details] only the abstract generic dynamic contribution item class
Created attachment 190911 [details] fix that includes everything
Created attachment 190923 [details] fix that includes everything
This fix works for both toolbar and popup items for multiple views, pinned views with pinned context, and multiple workbench windows. I test it for cdi debugger, dsf debugger and our debugger. Marc, Mikhail, Patrick, Could one or some of you review this patch and let me know you have any concern? If everything looks good, I would like this be included in M6. Thanks.
(In reply to comment #12) > This fix works for both toolbar and popup items for multiple views, pinned > views with pinned context, and multiple workbench windows. > I test it for cdi debugger, dsf debugger and our debugger. > > Marc, Mikhail, Patrick, > Could one or some of you review this patch and let me know you have any > concern? > If everything looks good, I would like this be included in M6. > > Thanks. It doesn't work with CDI sessions. The "Add Global Variables" action disappears when the selection changes in the Debug view. The only way to make it visible is to open the context menu in the Variables view. I thought we agreed to use the action set instead of trying to show/hide the actions dynamically.
(In reply to comment #13) When merging this patch to m7, the plugin xml shows erros that the commands and handlers for global stuff got wiped out by the debug view layout counterparts. Without those commands and handlers, then it does not work. Is the actions set the mechansim to be used to control the visibility for cdt debug in general? If the actions set is enabled by the user, will the three actions get the same problem with pinned context and multiple instances of variables view that I see in 340478? Also, I looked at other cases that use actions set to control visibility, e.g., debug view layout, trace points, reverse debugging. Their inital visible value are set to false and rely users to turn them on. If I follow this mechanism for global debug variables actions set with initial visible value being set to false, is this acceptable to cdi debugger users that they have to turn the actions set on either manually or through some other mechanims? That is to say, after installing a new epp cpp package, they will no longer see the three buttons unless they take a further action to enable the actions set. If this is agreed by everyone, I can submit another patch using this approach.
Created attachment 191874 [details] all_fix get migrated to m7
(In reply to comment #14) > Also, I looked at other cases that use actions set to control visibility, e.g., > debug view layout, trace points, reverse debugging. Their inital visible value > are set to false and rely users to turn them on. > If I follow this mechanism for global debug variables actions set with initial > visible value being set to false, is this acceptable to cdi debugger users that > they have to turn the actions set on either manually or through some other > mechanims? That is to say, after installing a new epp cpp package, they will no > longer see the three buttons unless they take a further action to enable the > actions set. > If this is agreed by everyone, I can submit another patch using this approach. I've never tried it, but can we automatically enable an actionSet based on DebugContext? I think hiding the CDI buttons by default is not very user-friendly. How about Capabilities, would that be a better solution? I've never used them but we do use them in CDT.
Hello all, I'm using dsf debugger : adding global variables through Variables view is disabled (eclipse 3.8 + CDT 8.1.1). I find that your previous investigations looked just arround limiting the add of global variables just for cdi baded models (for dsf debugger, the feature is disabled as you test ability basing on DebugElement information)? Did you plan any investigation for supporting "Global Variables" with DSF debugger ? Thanks in advance Maherzia
Mike Wrighton has initial patch for GDB MI command for this (almost ready) as well as initial DSF implementation, but we don't have time immediately to complete the DSF part.
Thanks for the reply. Please where could I find Mike's initial patch ? Do you plan to complete this patch in order to be included in CDT 8.2 or newer CDT version? Thanks in advance
(In reply to comment #19) > Thanks for the reply. > Please where could I find Mike's initial patch ? > Do you plan to complete this patch in order to be included in CDT 8.2 or > newer CDT version? > Thanks in advance It is very much work in progress so there is no initial patch available yet. I'm afraid I can't give any estimates as it's not on my current plan (although the patch for the GDB part will be ready soon). We're actually still having discussions about the usage model for this feature, specifically what method of filtering would be most appropriate e.g. list all globals per source file, list all globals per object file etc (the primary reason for using such a filter being to reduce the command time inside GDB). If you have any suggestions for what the best interface would be from a users point of view, that would be useful.
From user point of view, I vote for listing global variables per source file (in a tree): but I think it won't reduce time expended by gdb command (as it lists all variables at the end) Is there a way to view just global variables associated to the current debug context (such as local variable behaviour). Then, Source file name (or path to source file) could be viewed in the tooltip of each global variable. Hope it could be usefull :) Just a little question how did you fit "DebugElement" (or current stack frame) while attempting to use dsf-gdb ? Thanks
My last question deals with "Bug 343911 -add/remove global actions for variables view should be overridable for non CDI debuggers" In fact, I think that your ongoing investigation fixed in some parts this bug.
