Talk:Debug Platform/Planning

This page is intended for discussion of the Debug Platform planning page. It can include notes about the items themselves as well as meeting notes, etc.

Notes about content

Modularity

• Asynchronous viewer framework
  • Conclusions drawn from discussion in bug 161434:
    • The flexible hierarchy viewer is different from databindings and common navigator in a fundamental way, in that it uses completely asynchronous APIs. For this reason alone, it is unlikely that it could be merged with either of these other frameworks.
    • This framework could be contributed to jface if the vague impression of the architectural mismatch with SWT could be overcome.
    • Filtering behavior needs to be fixed.

Platform

Spawner

CDT has support for this now, but this could be moved down to the platform

This would allow the Java debugger to support operations like CTRL-C and CTRL-Break in the console

229219

My original idea was to port all debug.ui actions to the command framework, but I think this is too ambitious without any obvious benefit. -Pawel.piech.windriver.com 18:28, 19 August 2008 (EDT)

CDT breakpoint actions

I don't remember what this items was referring to? -Pawel.piech.windriver.com 18:28, 19 August 2008 (EDT)

CDT supports so called action breakpoints. Ken proposed to move it to the platform. --Mikhail.Khodjaiants.arm.com 09:57, 20 August 2008 (EDT)

Workflow

• Debugging without the debug view or debug perspective

  Active debug context switcher

  An obvious solution is to use a popup dialog,

  Another option could be a bread crumb solution, which could provide both navigation and feedback.

• Debug toolbar

  AlanB: some customers have sized the debug view until it just shows the toolbar to get around the fact that they can't have just the debug toolbar.

  Could we get workbench support to allow action sets to appear in menus and/or toolbar selectively?

  Update: I submitted a feature request with Platform UI (bug 244583), to allow users and perspectives to optionally suppress a toolbar contribution in an action set. Hopefully this can address the concern that the Debug toolbar would take up too much screen space. -Pawel.piech.windriver.com 00:48, 20 August 2008 (EDT)

• Debugger tooltip enhancements

  Instant debugger tooltips

  May require some infrastructure changes for tooltips in the platform ui.

  • Additional tooltip improvment ideas:
    • AlanB: pin the tooltip to the variable so that it follows it as the editor is scrolled
    • AlanB: show hovers for each variable on the current line
• Breakpoints presentation
  • The pre-requisite work item here is converting the Breakpoints view to use flexible hierarchy viewer, which may require significant effort in development and testing. -Pawel.piech.windriver.com 00:48, 20 August 2008 (EDT)
• Additional ideas:
  • AlanB: Add ability for Variables view to just show variables on the current execution line.
    • I believe this should be possible with existing support. It's only a matter of implementing a the variable view content provider capable of using the current stack-frame's PC as context. -Pawel.piech.windriver.com 00:48, 20 August 2008 (EDT)

• Multiple-context debugging
  • The content for this section originated from the multi-context proposal in the Device Debugging project DSDP/DD/MultiContext.
  • The goal: Allow multiple debug sessions to be equally share screen space in a single window

• Debug working sets

  Just like the resource system, the debugger can quickly overwhelm the user with data. The resource system provides working sets the help the user manage all this information. So far, an equivalent system is missing in the debugger. Part of the problem is that the debugger data is much more dynamic than the resource system, so implementation of a debug working set may need to be much different than the resource one and will need to allow for elements to be added/removed based on filters rather than on a fixed set. The features of the Debug Working Sets would include:

  • A Debug Working Set allows the user to add any debug elements from the Debug view or other debug content provider.
  • The working set stores the elements as mementos rather than actual object instances. If multiple objects match a given memento, they are all all included in the working set.
  • A Debug Working Set can have an icon decorator and a label associated with it. Per user preference, this decorator and or label is added to its elements when displayed in Debug view and elsewhere.

• Multiple instances of debugger views

  Allowing multiple instances of views is rather easy, managing the active contexts of multiple views is the difficult part. The complete feature would include the following provisions:

  • The debugger views include a view menu and tool-bar action to duplicate the given view.
  • These views would allow the user to change the input of the view from the the window's active debug context to any debug context, using the debug context selection dialog.
  • Once the view is focused on a particular context, its content description shows that context's label. This is the same label as the one used in the status bar active debug context control.
  • Additionally, rather than explicitly setting the input context of a debugger view, a user may restrict a given view to a working set.
  • When a debugger view is restricted to a working set, it changes it's input only when the active debug context is within this active working set.
  • Also, when a debugger view if restricted to a working set, as an option, that working set's decorator is added to the view's icon and the working set label is shown in the view's content description.

• Debugging with multiple editors visible

  The multiple debugger views could be useful when debugging multiple contexts simultaneously, but they will not be that useful if the source from only one context will be visible at a time. Currently, the user is able to arrange multiple editor side by side in the editor area. However, there API to allow the debugger to ensure that an editor is opened in a particular section of the editor area. There are two ways to solve this:

  1. Add functionality to workbench editor area management:
     • Add an API to workbench to allow the debugger and other clients to identify and target specific editor areas.
     • Add a feature in the debugger to open editors for a specific working set in a specific section of the editor area.
  2. Create a "source viewer" editor.
     • As the user steps through the code, the source viewer is used to show the code and the IP instead of the standard editor associated with the given content type.
     • The source viewer editors probably need to be debug model specific, and content-specific.
     • The source viewer can be restricted to a given working set just like other debugger views.
     • The source viewers can be arranged as needed by the user in the editor area, so that multiple debug sessions can share the same window's editor area.

Meeting Notes

Wednesday, July 2nd, 2008

Initial discussion.

Thursday, August 21st, 2008

There will be a phone meeting held at 11AM CST (12PM EST, 9AM PST) on Thursday, August 21st, 2008 to gather and dicuss these ideas. Please add your ideas here and join the meeting to discuss:

• Toll-free dial-in (North America): 1-866-245-5059
• Global toll free: 800-4444-1010
• Conference ID: 1696709

Agenda

• Pawel: bug 244583 and Debug toolbar.