Bugzilla – Full Text Bug Listing
| Summary: | Debugger support for roles and activities | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Alan Boxall <boxall> |
| Component: | Debug | Assignee: | Platform-Debug-Inbox <platform-debug-inbox> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | darin.eclipse, eharris, eric.estievenart, jared_burns, mqm, who |
| Version: | 2.1 | ||
| Target Milestone: | 3.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Alan Boxall
Investigating the concept of "debug context". So far I have collected the following ideas: * A debug context is a concept that is seperate from a debug model. For example, a debug context is something like "java", or "JSP", or "C++". A debug model is something like JDI or PICL. * The relationshop of debug model to debug context is 1:N (for example, JDI is used for both "java" and "JSP"). * A context is associated with a launch (perhaps a launch config type) * The relationship of launch config type to context is N:1 (for example, remote Java and local Java both represent the "java" context). Plan to allow views/actions to be contributed for a context. Contexts can be turned on/off allowing views/actions to be shown/hidden. *** Bug 22396 has been marked as a duplicate of this bug. *** *** Bug 24410 has been marked as a duplicate of this bug. *** *** Bug 36095 has been marked as a duplicate of this bug. *** *** Bug 36986 has been marked as a duplicate of this bug. *** The workbench now supplies contexts and action contributions based on contexts. Need to investigate use of contexts to support view and action visibility in the UI. When the "java debugging" context is activated (by launching a java debug session), the java debugging actions and views should become available. We do not intend to remove actions/views once they become availabe (to promote a stable UI). Note that some debugger related actions will need to be present in the "java development" context (such as adding breakpoints), which needs to be available before launching a program. Need to experiment with "role" support provided by UI to determine if roles can help solve these problems. Using the current roles and activities support, I've added filtering to the launch config dialog, launch history menu, "organize favorites..." dialog, and the breakpoints view. I've filed a number of requests to the UI team, but what they're currently supplying seems to do the job for us. DarinW, do you want me to release the current code to CVS? Yes please. We will just need to keep up to date with the workbench (to avoid breaking builds). Released support as described in comment #9. Filed the following two bugs which limit the effects seen by enabling/disabling activities: Bug 45746 - [Preferences] Disabling activity doesn't disable child preference pages Bug 45825 - Perspectives don't respect activity enablement I've made our support more light-weight. We no longer provide any activities. We just provide activity bindings that link Java Debug and Java Launching support to the "Java Development" activity. Currently, the platform provides a "Debugging" activity, but I don't think we actually want this because you need to be able to do debugging things (setting breakpoints, in particular) before you actually start debugging. I think other providers should follow our example and link their debug/launching actions to the appropriate "development" activities in their domain. DarinW, if you agree, please take this report and verify. I agree with this. Since the RCP has been separated from the IDE, there is no need for a separate "Debugging" activity. Debugging is inherently part of development activities. Marking as "fixed" for M5. Other debug implementors should examine the role support provided by the workbench to see if this meets their needs for filtering views/actions from the debug perspective. Debuggers may need more dynamic support than is provided by roles and activities. Since different debuggers share various common subsets of views, it may be better to close/open views dynamically based on what targets are currently active/selected. This support is not currently provided by the workbench. We have support for activity filtering in the Launch dialog, launch history, and breakpoints view. Support for dynamic views/actions in debug perspective is handled by another feature/bug report - see bug 53548. The SDK is to provide a set of relevant activity definitions. Marking as fixed. We will open other bugs as required to address activity filtering. Verified. |