Re: [platform-debug-dev] [Fwd: Re: [cdt-dev] catchpoints design]

[Pawel Piech <pawel.piech@xxxxxxxxxxxxx>]

Darin Wright wrote:

I'm cross-posting this to the platform mailing list since this is 
kind of a general debug workflow issue....

Hi All,
In CDT we're discussing adding support for additional breakpoint 
types which are supported by only some CDT-based debuggers.  In 
order to avoid cluttering the UI with irrelevant actions, we are 
discussing whether and how to filter these breakpoint actions based 
on the active debug session.  I actually think that this problem 
also applies to JDT and other debuggers, since for example in the 
Wind River product we get regular complaints about "Add Java 
Exception Breakpoint" being present in the Breakpoints view toolbar.

So my question to the platform team is:
1) Do you think that filtering breakpoint actions based on the 
active debug context makes sense?
    

I agree that it would be nice to be able to filter the breakpoint creation 
actions based on some context. The problem here is deferred breakpoint 
creation. If the actions are filtered based on active debug context, then 
how can I create a breakpoint before a debug session starts (like a Java 
exception breakpoint) ?
  

The File->New menu always has an "Other..." entry which opens a wizard with a categorized selection page.  BTW, I don't think that active context needs to be the only method for determining whether a given breakpoint action is visible.  For the CDT breakpoints we're discussing, there is a lot of variability in support from different debuggers, even from different targets.  For more standard breakpoints types, it may be more appropriate to filter based on active action sets.

2) Do you think such a filtering mechanism should be standard and 
supported by platform?
    

If we can find a good way to do this - yes.

  

3) Do you think the File->New mechanism is appropriate for this 
purpose as I suggested in the CDT discussion at (http://wiki.
eclipse.org/Talk:CDT:_Debug:_Catchpoints_support#File_-.3E_New).
    

"File -> New" feels heavy for breakpoint creation. Generally this is 
reserved for things that create new entities in the file system.
  

As a marker a breakpoint actually is in the file system :-) 
I and most people in the discussion I think have the same concern.  One option is to just not use the New wizard framework and just copy it, but to me that seems to go against the spirit of Eclipse... There are also some real advantages to using the File-> New menu:
- The wizard interfaces and extension points are already in place.
- There is already a menu and a toolbar action for it.
- It's a familiar user workflow (even if it's not yet used in debugging).
- The File->New shortcut menu is empty in the Debug perspective, giving the breakpoint actions a clean slate.

This is just a far-fetched idea at this point, but IMO clutter in the Debug UI is a real pain point for Eclipse users, so I want to find some ways to address it. 

Cheers,
Pawel

Darin Wright
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev