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

Revision as of 13:02, 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)

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)

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)

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)