| Summary: | [plan item] Present logical view of Java objects in debugger | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Jim des Rivieres <jeem> |
| Component: | Debug | Assignee: | Luc Bourlier <eclipse> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P4 | CC: | boxall, Darin_Swanson, eclipse, eclipse, eclipse, m.a.r.k |
| Version: | 2.1 | Keywords: | plan |
| Target Milestone: | 3.0 M5 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Jim des Rivieres
*** Bug 36591 has been marked as a duplicate of this bug. *** Will investigate an approach that enhances the 'details pane'. The idea is to promote this pane to a full-fledged view (as in the hierarchy view). There will be an extension point where an implementation for this view can be contributed for a specific type. By default, the existing String-oriented view will be used for all types that are not otherwise assigned. Released first cut at infrastructure and a small set of specific filters for Java. Content providers can be registered for a debug model. When a CP is registered for a debug model, the variables view delegates to that CP for all variables belonging to that debug model. In the case of Java, this CP in turn looks for CPs registered against specific Java types (classes or interfaces). The first matching CP found searching up in the class hierarchy is used. The children returned by custom CPs are encapsulated in 'placeholder' variables, that are constructed from a name and an IJavaValue. These placeholders are represented with a different icon in the view. All infrastructure to quickly create new Java 'variable filters' (specific CPs) is public API. Next step is to consider how to manage variable filters. At present, all registered filters (content providers) are used all the time. Variables that qualify for > 1 filter will use the one nearest to them in the hierarchy. In case of collisions, there is no rule as to which filter is used. Proposal is to implement some type of dialog that allows users to have control over which filters are in use. For example, have an action "Variable Filters... " in the context menu for a selected variable in the VariablesView. This opens a dialog containing a checkbox list. All registered filters that COULD apply to the selected variable type are listed, and the one currently in use is checked. The choice made in this dialog then applies to ALL variables of the same type until the choice is changed in the future. This allows multiple, overlapping filters to be registered by many different plugins, with the user having the choice of which to use. Decided to omit any sort of management feature for now, since the estimated number of filters is low. Also decided to avoid any sort of optimization work for now since the there would be extra complexity and memory footprint for a small benefit. Marking as fixed. Please verify, Darin W. New interfaces need review and better documentation. Deferred to M4 How does the user know which, if any, object browsers are available? Currently, the user does not know which browsers are defined - you'd have to look at the extension points for the java debugger that contribute browsers. I have re-worked the way logical structures are contributed/computed - existing experimental "object browser" extension points have been removed. The new experimental story follows: * an extension point "logicalStructureTypes" has been added to org.eclipse.debug.core (not yet documented - and is an internal class - see ILogicalStructureType, and ILogicalStructureTypeDelegate) * A "logical structure type" provides a logical value for a raw value, for a specific debug model. When a value is expanded in the variables view, contributed logical structure types (for the applicable debug model) are queried to see if a logical structures (translation) is available for the value being displayed. * by translating a value, rather than providing a "content provider" (as the first approach used), we can allow logical structures to benefit from the automatic array partitioning provided by the debug model. For example, a collection can be translated to an array, and it will be automatically partitioned in the UI. As well, logical strucutres are now supported in the expressions view. API will remain in "experimental" mode for a while (until M5?). Need to add user interface for choosing a strucutre to display when more than one translation is available for a value. The API has been made public: ILogicalStructureType ILogicalStructureTypeDelegate new extension point: org.eclipse.core.debug.logicalStructureTypes UI has been added to select from available strucutre types when there is more than one for a selected variable. As well, the user may selectively disable structure types. A drop down menu/action has been added to the variables view that displays all available structure types for a selected variable. The enabled structure is checked. Infrastrucure is in place. Marking as fixed. New bugs should be opened as required. Please verify, Luc. Verified. |