Community
Participate
Working Groups
Currently to edit properties such as skip count, condition, temporary, filter, etc. User has to first create a breakpoint (which is then installed on target), then edit the breakpoint in the properties dialog. The user should be able to perform both actions in one step.
Emphatic +1
Concur, emphatic +1. Pawel, what help do you need? I am also working on breakpoint support.
(In reply to comment #2) > Pawel, what help do you need? I am also working on breakpoint support. Hi Bruce, The initial focus from our POV is to migrate capabilities we have in our product's breakpoints to CDT. Since we have working code in our product that we'd like to migrate we're in a good position to move quickly and plan to have these features completed by end of the year. However, there are many other cool breakpoint features we'd like to see. For example, one breakpoint feature that's sorely missing in CDT breakpoints is a detail pane for breakpoints. IMO, the most useful breakpoint detail pane would be something like a container for the breakpoint properties pages, which would fit in the detail pane sash. JDT breakpoints have a customized detail pane that's different than the property pages and IMO it's confusing. Another frequently requested feature is better breakpoint filtering and presentation in the UI. I'm curious to know what breakpoint features you're currently working on, though we should probably move this discussion for cdt-dev.
Is this going to replace the default "add breakpoint" action behavior (Ctrl+Shift+b or editor ruler doubleclick) or be a new action?
(In reply to comment #4) > Is this going to replace the default "add breakpoint" action behavior > (Ctrl+Shift+b or editor ruler doubleclick) or be a new action? New action. In our product, we added menu items for these actions in the main menu under Run->Breakpoints, in the Breakpoints view menu, and in the editor gutter. It kind of grew organically, so maybe that's an overkill to have all these options. OTOH, I think it'd be nice to use the Ctrl key modifier on the editor gutter double-click in order to bring up the dialog. Of course, opinions are welcome.
The following changes should be made to the breakpoint properties dialog design (see the diagrams in 1. Introduce a central preference store. The preference store in the properties dialog will be initialized using the raw attributes extracted from the breakpoint marker. Likewise, upon okPressed() the attributes from the preference store will write out to the breakpoint. 2. Update property pages to use the central preference store. The property pages need to be updated to read/write attributes to the preference store instead of directly to the breakpoint. Pages that support this new paradigm can identify themselves with a marker interface, or using another parameter in the property page filter. 3. Allow properties dialog on breakpoints without a marker. We need to add an API for creating CDT breakpoints without the corresponding marker (and thus without registering them with the BP manager. Then the properties dialog could be opened on the marker-less breakpoint object. This is where it's important to identifying pages that support reading/writing to preference store rather than the breakpoint object directly. Pages that require a valid breakpoint marker in order to work, should not be allowed. 4. Handle breakpoint extensions. Currently breakpoint extensions can make an assumption that a marker should be present on a breakpoint, or they can log an error. For property pages that are accessed by property pages from point 3, those corresponding breakpoint extensions should be updated to expect a breakpoint without a marker. I'm not sure if we'll need any new API to notify extensions of when the actual marker is created. 5. Polish the new actions.
> OTOH, I think it'd be nice to use the Ctrl key modifier on the editor gutter double-click in order to bring up the dialog. This sounds really awesome. Some suggestions: 1. Using Alt may be more consistent with Mac where "Option" key is often used to slightly alter the action behavior. 2. Ctrl (or Alt) click on an existing breakpoint may open property dialog instead of removing the breakpoint.
(In reply to comment #3) > However, there are many other cool breakpoint features we'd like to see. For > example, one breakpoint feature that's sorely missing in CDT breakpoints is a > detail pane for breakpoints. Another big feature that is in demand is have target-specific breakpoints. It is kind of an extension of the concept of thread-specific breakpoints, which we already support. The idea is that the user could create a breakpoint for a set of targets instead of everything the debug view knows about. The breakpoint on each target could be controlled independently, where you could enable the breakpoint on one core, while keeping it disabled on others, for example. There is an example of this idea in the below presentation from EclipseCon at slide 17. http://wiki.eclipse.org/images/6/69/MultiCoreDebugEclipseCon11.pdf
I got working an initial take at implementing this feature. The link to the patch is https://github.com/wind-river-cdt/cdt/commit/2b6a4ec8c38e3c26c5e825c98eef8411209abffb. This patch depends on the latest patch for Bug 369856 in order to enable the modified toggle action. To set a breakpoint with a dialog, shift-double click on editor gutter, review the options and press OK. I also added an "Add Breakpoint ..." context menu item that does the same thing. There's a few minor API changes I needed to make to make this work: - Added methods to CDIDebugModel to populate the default breakpoint attributes into a map instead of directly into a breakponit marker - Added constants with marker type IDs to various breakpoint interfaces (e.g. ICLineBreakpoint.C_LINE_BREAKPOINT_MARKER). - Modified the handling of org.eclipse.cdt.debug.ui.breakpointContribution to take into account the attribute type (previously it was ignored). - Defined a new property and added a property tester to allow a property page to be contributed for a breakpoint before the breakpoint marker is created. The last item was the most complicated. I wanted to make sure that the only property pages that will be shown for a breakpoint to be created are ones that were explicitly designed and tested to work with a marker-less breakpoint. Therefore, in order to contribute a property page for such breakpoint, the property page must use a new enablement expression with the fore-mentioned property tester. My next steps are to enable interactive toggle action for other breakpoint types: watchpoint and method bp. I'll probably file bugs to convert the event breakpoint action and to update the disassembly view.
Created attachment 210835 [details] Diff patch. (In reply to comment #9) On Mike Rennie's request I refactored some of the toggle breakpoint API changes which enable this feature (see bug 369856). I updated the CDT patch with corresponding changes as well as merging changes for bug 360588. The latest changes are in branch: https://github.com/wind-river-cdt/cdt/tree/wind-river-breakpoints_add. Since the commits are separated by a merge I'm posting the diff here.
Work in progress: https://github.com/wind-river-cdt/cdt/commit/14ffeec6a8ec3a6ba4c0d5eef3be9ccd08296d65 I refactored the toggle and other breakpoint classes a bit: - Made AbstratToggleBreakpointAdapter an API class so that CDT extensions can create more specialized breakpoint actions. - Added ability to toggle method breakpoint interactively: hold Control key while selecting Toggle Breakpoint from menu in outline view. Next I'll try to refactor the add event breakpoint dialog and other breakpoint dialogs to go through the toggle adapter as well.
We decided to split the APIs that support this bug. I'll post the updated patch in a bit.
https://github.com/wind-river-cdt/cdt/commit/c61c70d978b7aaf01233b23196c988931075a7e6 I updated the cdt breakpoint changes to work with committed changes from bug 346615 and my planned changes for bug 369856. I think this patch is complete aside from comments on the new APIs. Once I get bug 369856 settled I'll plan to commit this change.
I have a version of the changes ready that I think I can satisfy this bug: https://github.com/wind-river-cdt/cdt/commit/0b5f7b2f515cc23d6335d8099a2392aa4e361c8a The features include: * Support for new toggle action modifiers on the editor gutter: Ctrl-dobule click to edit a breakpoint or create a breakpoint interactively (i.e. open properties dialog before creating the breakpoint). Shift-double click to enable/disable.
(In reply to comment #14) > The features include: Oops didn't get to finish my thought, here's the full writeup: * Support for new toggle action modifiers on the editor gutter: * Ctrl-dobule click on an existing breakpoint to edit its properties * Ctrl-dobule where there is no breakpoint to create a breakpoint interactively (i.e. open properties dialog before creating the breakpoint). * Shift-double click to enable/disable existing breakpoint * On editor gutter context menu "Add Breakpoint..." action will open a breakpoint dialog with file and line# filled in. Upon OK, the dialog will create the breakpoint. * In the outline view context menu. Hold Control key while selecting "Toggle Breakpoint" will open the properties dialog on the method breakpoint to be created. Still to do: will follow in separate bugs: * Convert "Add Event Breakpoint" to use toggle API. * Convert "Add Watchpoint" action to also use toggle API (and let the actions create toggle non-C breakpoints too). * Arbitrary expression breakpoints. * Allow breakpoint extensions to be edited prior to creating breakpoint (actions, filters, etc.). On the implementation side there's quite a few of changes. The biggest architectural change is to expose in the APIs the fact that breakpoints are mainly just a property map. This allows the actions to act on the properties before the breakpoint is fully functional. In more detail: 1) In CDTDebugModel class, I added actions which allow clients to create a "blank" breakpoint (i.e. without a marker), then to edit the properties, and finally create a marker onto an existing breakpoint. 2) In breakpoint properties dialog, I switched the common page to read and write data into a custom property store. This property store then reads/writes data to the breakpoint marker. Field editors had to be updated not to access breakpoint marker directly. Any other pages that are to support editing properties prior to creation will need to be updated as well. 3) Refactored packages to separate breakpoint-specific actions. 4) Made a base class of toggle breakpoint adapter an API. This is not strictly a requirement for this feature, but it's a logical extension. Just as a property dialog can be used to edit the breakpoint prior to creating, custom toggle breakpoint adapters can be used to modify breakpoint properties based on debug context prior to creating breakpoint (e.g. define breakpoint filter for active thread). I will keep testing and update the patch as needed, but I'll plan to commit this right before M6. Reviews would be much appreciated.
Update: I found a problem contributing TCF-debugger specific pages to the add breakpoint dialog. To solve the problem I added ICBreakpointContext interface which makes the previously hidden object part of the breakpoints UI API. This change is still in my branch: https://github.com/wind-river-cdt/cdt/commit/e80ea700999c1371fd123dee64d6fa2bdc6a23e9 We are nearing M6 in platform so I plan to commit these changes to CDT repo this Friday.
I made a bunch more improvements for this bug: https://github.com/wind-river-cdt/cdt/commit/8f942702abccd5641869649c86c9ab2b64682594 Specifically, the commit includes: - Added support for double-click action modifiers in the Disassembly view. - Added an "Add Breakpoint..." action to the Disassembly view as well. - Converted the Breakpoints view's "Add Watchpoint (C/C++)" action to use a full breakpoint properties dialog when creating a watchpoint. - Added an "Add Function Breakpoint (C/C++)" action to the Breakpoints view. The action opens the full properties dialog and allows user to enter the function name. The only thing left as far as I know is to convert the remaining Add Watchpoint actions to use the toggle adapter instead of the limited AddWatchpoint dialog.
I pushed the changes to eclipse repo. I'm marking the bug as fixed and will open separate bugs for any remaining work as needed. http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=7c1e0556b62d6db469a472ba86df4dcc0505f6db http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=7c1e0556b62d6db469a472ba86df4dcc0505f6db http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=7872ff527c6dc66182da5af7e427ec808a586772 http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=b9f5e87587dae4cecab6e29853c873caa090a055 http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=8b6befdf03a49f4ee073b1aef05c7094d8f268da http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=d76485935eae38374d7e233a6a0ab383957b0f8e http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=bfdf65cacdce33a493017a43fdb5ecd3613ff13f http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=dd069579ac0131db85c7673c43556ecbb9b7432b
I updated N&N for this feature: http://wiki.eclipse.org/CDT/User/NewIn81#Function_Breakpoint_Manual_Entry
I fixed a bug in the following workflow: Control key with Toggle Method Breakpoint 1) Open the editor's Outline view. 2) Right-click on a method to bring up the popup menu. 3) Hold the control key while selecting the Toggle Method Breakpoint action. 4) This brings up the function breakpoint dialog pre-filled with the method name. Pushed the fix: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=54b5e33af4d732b2831762c6bb150ebadcd773cc
(In reply to comment #19) > I updated N&N for this feature: > > http://wiki.eclipse.org/CDT/User/NewIn81#Function_Breakpoint_Manual_Entry Awesome! I think it deserves to be higher up in the list of N&N. I'd say at least 1.4
I made another change for this bug to restore the old AddWatchpointDialog after I found that moving it broke backward compatibility with TCF: bug 374983. http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=2789b67a23b425dec4fe00fc90058ac5be727cce
*** cdt git genie on behalf of Pawel Piech *** Bug 360588 - [breakpoints] Allow user to edit all its properties prior to creating the breakpoint Restored original AddWatchpointDialog for backward compatibility. [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=2789b67a23b425dec4fe00fc90058ac5be727cce
*** Bug 400791 has been marked as a duplicate of this bug. ***
