Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Debug Platform/Planning"

(Debug Platform 3.5 and 3.*)
(Debug Platform 3.5 and 3.*)
Line 34: Line 34:
 
** Decorate breakpoints according to active debug context (bug 238954)
 
** Decorate breakpoints according to active debug context (bug 238954)
 
** Improve usability of the breakpoints view (bug 238956)
 
** Improve usability of the breakpoints view (bug 238956)
 +
* Ken: Allow plug-ins to extend/modify/cancel launches (bug 175538)
 +
* Ken: Move breakpoint actions from CDT to the platform
  
 
== Debug Platform e4 ==
 
== Debug Platform e4 ==

Revision as of 18:23, 1 July 2008

This page is gathering place of ideas for the future evolution of the Eclipse debug platform (3.*, and e4).

There will be a phone meeting held at 10AM CST (11AM EST, 8AM PST) on Wednesday, July 2, 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

Debug Platform 3.5 and 3.*

  • Support process IDs and system signals at the platform level
    • 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
  • Support EFS (external file system) for launch configuration persistence
  • Asynchronous viewer framework
    • Compare with existing JFace tree databinding
    • Create a JFace component for the framework
    • Pawel: DSF View Model as a solution to the single adapter problem?
  • Debugging without the debug view or debug perspective
    • Lightweight context switching (quick pop-up to select new context)
    • Where should the debug toolbar reside?
    • Is there a need for lightweight variables view or "debug dashboard"?
  • Create more meaningful performance tests and backport to 3.4
    • Pawel: a virtual tree viewer as a test tool and for copy, find, etc.
  • Debugger tooltip enhancements
    • Instant debugger tooltips, without waiting for operating system delay (may require some infrastructure changes for tooltips in the platform ui)
    • Each time you step, tooltip automatically refreshes the displayed value
  • Expressions view: click or double-click to add or edit expressions in-line (without dialog)
  • Pawel: Peaceful coexistence of different debuggers
    • Make it easier to create different breakpoint types from the same editor (bug 212316)
    • Make run to line adapter async. (bug 21074)
    • Port debugger actions to command framework? Related: bug 229219.
  • Mikhail K: Breakpoints presentation
    • Decorate breakpoints according to active debug context (bug 238954)
    • Improve usability of the breakpoints view (bug 238956)
  • Ken: Allow plug-ins to extend/modify/cancel launches (bug 175538)
  • Ken: Move breakpoint actions from CDT to the platform

Debug Platform e4

  • Use services instead of singletons (launch manager, expression manager...)
  • Separate launching into a new component, that can be used without debug
    • Consolidate/simplify launching APIs (mixed mode, launch shortcuts, contextual launch)
    • Should we continue to use launch configurations, or consider an architecture that would allow aspects of a launch be used more easily to compose different types of launch configurations (e.g. JRE, Source lookup...)
      • How can we make the UI for a launch aspect more reuseable?
    • Merge external tools with run/debug
    • Support for multi-launch
    • Provide direct access to a process's input/output streams (no need for StreamsProxy)
    • Namespace for launch configurations should not be flat
  • Moving forward what happens to the standard debug model? DSF?

Back to the top