Difference between revisions of "Talk:CDT/Archive/Debug/Catchpoints support"

Revision as of 15:00, 11 April 2008

This a page for discussing content of the CDT:_Debug:_Catchpoints_support page. See Wikipedia Talk Page Guidelines for guidelines on editing this page.

Workflow & UI

I think putting the add breakpoint command into the breakpoint view context menu violates some Eclipse UI guidelines. The proper place to place this action would be in the Run top level menu. That said, JDT breaks this rule also by placing the "Add Java Exception Breakpoint" action into the breakpoints view toolbar.

IMO, we should try to define a new retargetable action for "Add exception breakpoint" and collaborate with Java to use it as well.

-Pawel.piech.windriver.com 15:39, 9 April 2008 (EDT)

1. Well I though I use same place where current Add watchpoint is... If we add command to the Run would anybody find it? Actually What guildlines you refer to, I don't think it applies here. Breakpoints view manages breakpoints, user can remove them and user should be able to add them there. It should not be context menu, but it can be toolbar or view menu action.

2. Java exception breakpoint is not the same, it is just of one of Catchpoints variations... If we make it retargetable we have to change its name too

Elaskavaia.qnx.com 15:59, 9 April 2008 (EDT)

1.

• Section 1.7.5.5 "A context menu should be used for context sensitive interaction with the objects in a view." - The "Add Breakpoint..." action is not a selection-oriented action. Granted there are other examples of this, such as "Add Watch Expression..." in the expressions view, but that doesn't make it correct.
• Section 2.3.2 - The whole section is dedicated to why the context menus should be kept short and simple.
• Section 1.7.7.1 "Guideline 9.2: Follow the platform lead when distributing actions within an Action Set." - Platform has established the Run menu as the place to add global breakpoint actions. JDT has also followed this list. I'll admit that the run menu is not the first place I looked for breakpoint actions, but if that is the problem then we should debate this issue with the rest of Eclipse community and ask platform Debug to make changes.
• Putting these commands on the main menu would allow users to disable the corresponding action set when they don't want to see these actions.

2.

• My main point here was that adding debugger-specific breakpoint actions (I mean JDT vs. CDT, vs. etc) makes the whole UI more cluttered and less unusable. This is something that Mikhail also brought and that's why he suggested to make the catchpoint commands be visible only when the corresponding context is active.
• Of course I agree that "Java Exception Breakpoint" is not ideal, maybe "Exception Breakpoint" would do :-) Perhaps I don't understand how catchpoints are semantically different from "Exception" breakpoints. IMO a signal catchpoint could still be though of as a form of an exception breakpoint.

-Pawel.piech.windriver.com 22:48, 9 April 2008 (EDT)

1. Yes I already agreed about context menu, it should not be there. We can add it in Run and in the View. And if we do that we should probably move Add watchpoint in the same place.

2. It is not even Exception breakpoint. It can be stop on loading shared library event.

-Elaskavaia.qnx.com 09:50, 11 April 2008 (EDT)

1. Great I'm glad we agree about the context menu use. However, I'm rather concerned about using the view menu as well because of the UI guidelines: [User_Interface_Guidelines#Menus_2 1.7.5.3]. This is what the Wind River product does and at first it seems like a logical place actions specific to the content of the view, but when you look at other views and what they have in the view menu, none of the standard views have actions which affect the content of the views, only their presentation. As far as the guidelines go, toolbar should also not be used for these actions, but with the java exception BP action there there may be more of a case for precedent. Of course, the problem with the toobar is that it gets cluttered so quickly, we can't afford to add many things there.

2. I think this question depends on the question from the Implementation section: are all catchpoints to be represented by a single action or should there be separate actions for different types of catchpoints.

-Pawel.piech.windriver.com 14:04, 11 April 2008 (EDT)

Catchpoint contributions

This is what BreakpointExtension mechanism would be useful for. -Pawel.piech.windriver.com 15:44, 9 April 2008 (EDT)

Isn't it more on core side? I was thinking more of ui control for specifics arguments. Can you elaborate on that?

-Elaskavaia.qnx.com 16:01, 9 April 2008 (EDT)

There is both a model and a UI side to this. A good example to follow is filtering breakpoints using threads. This page is model specific and there is a separate implementation for DSF. Specific debugger implementations can use this mechanism to contribute breakpoint property pages that are specific to their debugger.

-Pawel.piech.windriver.com 22:54, 9 April 2008 (EDT)

I don't see any ui extensions I can use. I can create extension to org.eclipse.cdt.debug.core.BreakpointExtension

but it does not have any defined interface and I cannot add ui class reference there because it is core...

Threads filter is hardcoded ui, it uses ICBreakpointFilterExtension but user cannot extend it, do I miss something?

-Elaskavaia.qnx.com 13:02, 11 April 2008 (EDT)

Clarification: the breakpoint extension mechanism is useful for adding debugger-specific breakpoint attributes and corresponding UI. By debugger specific I mean GDB, or Wind River, or Frysk, etc. I don't think you would want to use this extension mechanism to implement the generic catchpoint functionality.

To use this mechanism you would need to:

• Implement IBreakpointExtension with a class that declares and stores your debugger-specific attributes,
• Declare the extension using BreakpointExtension point
• Implement and declare a property page to edit properties in the extension (e.g. the CBreakpointFilteringPage)

-Pawel.piech.windriver.com 14:13, 11 April 2008 (EDT)

I looked at that. Unfortunately if I add property page for catchpoint it would look very silly - common page would be empty and misleading. I am thinking to extending Common page to support custom type randering.

Elaskavaia.qnx.com 15:00, 11 April 2008 (EDT)

Implementation

I think the implication here is that there would be a single action to create an event for any type of catchpoint. I'm a little concerned that this may be cramming too much unneeded complexity in the UI and in the API layers, because the needs of different types of catchpoints may be rather different. I vote for using different breakpoint types for different types of catchpoints, although this would make it all the more important to be able to filter the actions for these breakpoints based on debugger capabilities.
-Pawel.piech.windriver.com 23:03, 9 April 2008 (EDT)

I think gcc provides 10-12 different types of catchpoints. Adding them as separate action would be a way to much.

Don't you think?

-Elaskavaia.qnx.com 09:45, 11 April 2008 (EDT)

If these actions are not filtered in any way, then yes I think it would be too much. But as was indicated by Mikhail, the existing actions such as "Add Watchpoint" are already creating too much clutter for debuggers that don't implement them. So IMO it's a requirement for this feature to implement filtering of these actions based on the capabilities of the debugger. If the existing actions filtering features such as action sets, capabilities, command expressions, are not sufficient to implement appropriate filtering for this feature, then we should work with platform to improve them. I realize that this greatly complicates this feature, but it's really important to the overall usability of the CDT debugger.

Basically there are two options:

Option 1) I can add catchpoint specific breakpont type ICCatpoint, it will be similar to other types defined previously, such as ICWatpoint, ICAddressBreakpointe etc. In this case we use schema meaning marker type = catchpoint, specific types are marker attributes. I modify all places that has right now hardcoded switch for breakpoint interface type. This automatically mean it has only one action to add catchpoint.

Option 2) Instead we can add support for generic breakpoint extensions, there is some code there but there is no full support for that. Meaning in all "switches" we add proper handling of default interface (ICBreakpoint). Also it mean we add CGenericBreakpoint class because CBreakpoint itself is abstract class. In this case separate type can be created for each catchpoint event. The only problem I have with that is it will UI very cluttered.

-Elaskavaia.qnx.com 12:44, 11 April 2008 (EDT)

I also see Option 3) Add specific breakpoint types for different types of catchpoints: ICExceptionBreakpoint, ICSignalBreakpoint, ICThreadEventBreakpoint, ICProcessEventBreakpoint, ICLibraryEventBreakpoint, etc.