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

Asynchronous viewer framework

• 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.
    • From the August 21st 2008 meeting:
      • As mentioned in bug 161435, comment #9, there is little chance of combining databindings or common navigator with Debug's flexible hierarchy.
      • However there is interest in making the flexible hierarchy an API outside of Debug. To accomplish that, we would need to invest in refactoring the viewer implementation somewhat to make satisfy architectural concerns from the JFace team.
      • And as a pre-requisite to any refactoring we need a comprehensive test suite of the viewer to ensure that the debug functionality isn't broken. Pawel can contribute such a test suite as part of work on a Virtual Flexible Hierarchy viewer, which would be used for Debug View-less debugging.

Spawner

• 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)

Action breakpoints

• Platform

  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)

Debug view-less debugging

• 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)

    • From the August 21st 2008 meeting:
      • Adding the debug actions to the toolbar as part of the debug action set will work, as long as we can activate/deactivate the action set dynamically without the debug view present.
      • Debug View-less debugging is a pre-requisite to having the Debug actions on the toolbar present.

Tooltips

• Workflow
  • 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
    • From the August 21st 2008 meeting:
      • Daniel Megert is responsible for the JDT text infrastructure and could answer questions about tooltip/hover improvements.
      • The features may not need to be implemented in Platform Debug itself, but the Debug team could press for features in JFace text.

Breakpoints

• Workflow
  • 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)

Multi-context

• Platform
  • 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.

Memory view

• Workflow
  • Memory View
    • From the August 21st 2008 meeting:
      • Samantha:
        • Like the removing of monitors pane
        • Preserving backward compatibility of workflow is key
        • Need a custom "go to address bar", and would like to tie it to the rendering extension point.
        • Synchronizing renderings is a key requirement.
      • Pawel:
        • Go to address bar could be in the new tab area itself, but users would still need a popup to reposition an existing rendering.
      • Ted:
        • Users would like to see monitors for expressions, which get re-evaluated on every step, but Samantha says that renderings already support this.

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

Attendees

Ted Williams (WRS), Marc Khouzam (Ericssson), Mike Morearty (Adobe), Pawel Piech (Wind River), Darin Wright (IBM), Samantha Chan (IBM)

Agenda

• Ted: Memory view workflow enhancments bug 244822
  • WebEx: - https://windriver.webex.com/meet/pawel.piech, number=592 077 725, password=ecl1pse
• Pawel: bug 244583 and Debug toolbar.
• Async viewer framework
• Tooltips

Notes:

• Planning
  • Need to finalize milestone plan before M2. See "Eclipse 3.4 retrospect (take 2)"
• Statement of commitment (IBM)
  • +/- .5 person commitment
  • EFS support in launch configurations
  • Performance tests:
    • Better use cases with real user scenarios, still based on JDT.
    • Architecture meeting: a requirement for Eclipse project to have a written test plan including manual test plan, coverage of automated tests,...
  • Improving support for breakpoint export/import.
  • JDT: enhance support for different execution environmnets
• Statement of commitment (Wind River)
  • Pawel +/- 30%
    • Multi-context debugging, including debugging w/o Debug view
  • Ted:
• Statement of commitment (Adobe)
  • Tooltip improvments
  • Inline editing in Expressions view