Community
Participate
Working Groups
For the details view, a text viewer is not sufficient for some debug adapters. It would be nice if there was support that would allow debug adapters to provide their own details view handler.
Investigate for 3.1
Currently deferred
Re-opening for 3.3
Allow debuggers to contribute custom detail areas in the form of arbitrary SWT controls: * Provide an extension point for "detail area factories". A factory creates "detail areas" for applicable objects (variables, or whatever is selected in the variables view, which can display arbitrary objects) * A "detail area" will be initialized with the "workbench part site" it is contained in, to allow the detail area to create/contribute a context menu and participate as a selection provider (if desired) * A detail area will have a "type" (identifier), such that it can be re-used for objects that use the same kind of details area. The details area will have an API to "display(Object element)" the selected object. * We will support multiple detail areas per object and persist which detail area to use for a kind of object (similar to logical structures) * Factories will also provide name/descriptions for the types of detail areas it creates so we can fill context menus with available detail area options API will be something like: IDetailsAreaFactory String[] getDetailTypes(Object) - returns possible detail area type ids for an object IDetailArea createDetailArea(String id) - creates a detail area of specified type getName(String id) - returns name of a detail area type getDescription(String id) - returns description of detail type IDetailArea init(IWorkbenchPartSite site) createControl(Compoite parent) getId() getName() getDescription() display(Object element) dispose() (NOTE: We might want to come up with a better name than "detail area". These are really object inspectors, but "inspect" is also used in Java debugger's expression eval support. Ideas welcome.)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=153814 looks like a duplicate of this.
*** Bug 153814 has been marked as a duplicate of this bug. ***
I've attached a screenshot showing the GUI-rich register details section that we've implemented at Freescale. It involved adding a details-pane section manager to the view. Via an extension point, a plugin can register one or more sections. Each section gets either an expandable composite or a fixed one in which to put content. The sections update based on the selection change in the view, which is propagated to the sections by the section manager. The manager also provides the means for the sections to maintain and propagate a "pending" value, allowing the user to play around with a test value that updates all the sections but isn't written to the register until the user decides to commit to the value. I can't think of why we wouldn't contribute this to the community, but of course this might not be the solution you guys want. Perhaps it could be of some use to you. At a very minimum, we'll be extremely interested in helping you pin down the requirements and in being early adopters of whatever you put out.
Created attachment 53954 [details] screenshot
I would definitely be interested in seeing any code you have written. The setup you described is very similar to the API and infrastructure we were planning. I have already done some refactoring of the variables view code and it has the ability to use different types of viewers based on the current selection. I will be attaching a patch for this in the near future. So far I have been only testing the original source viewer and a simple table viewer. It would be interesting to test things with your complex register details section. Also, what Eclipse versions was your code written for?
We are working with a snapshot of the official releases of Eclipse 3.2 and CDT 3.1 that we maintain and evolve internally. The sections themselves are CDT based. What we could easily post are the platform changes--the framework for the sections. There's no rocket science there and it's not a ton of code. As for the CDT section extensions, that's going to be trickier. I'd need to seek internal approval for contributing that. Thing is, I don't know how useful it would be since it's based on a framework that will probably go away (assuming Darin's solution will differ significantly from what we came up with). What we could do is look at contributing the revised CDT extensions once I have them working on top of Darin's solution (whenever that becomes available).
Posting the framework you were using would be helpful. Yesterday, Darin and I developed a plan for the framework that is similar to what you have done. There may be code that can be reused, or if nothing else it may give me alternative ideas on how to implement it. I will post patches as I work so that people can test and make comments about the API. However, the patches will be targeted at 3.3.
My apologies, Curtis. I wasn't aware that you were a platform developer assigned to this work! (I was assuming Darin was going to do this work) I'll post our platform code today.
Created attachment 54024 [details] Our additions to the variables view that supports GUI-rich sections in the register details pane
Created attachment 54103 [details] Patch with refactored VariablesView and extension point Patch containing all the changes I have made so far. The VariablesView class has been refactored to separate the source viewer for the details pane. A framework/manager has been added to allow different detail pane types to be added using an extension point (org.eclipse.debug.ui.detailFactories). Several parts have not been completed, but feel free to make comments about the structure/API. I will be in Toronto until Wednesday.
Created attachment 54501 [details] Patch with context menu, enablement expressions, persistant prefs I have added a patch with all of my current work. I added a menu (Show Details As) to the variables view context menu that allows you to select what viewer you want. I included a table viewer that is only available if you select exactly three elements (done via enablement expressions so the factory is only loaded when needed). If you change the preferred details viewer, the choices will be persisted with the debug core preferences.
Created attachment 54751 [details] Proposed API (IDetailPane, IDetailPaneFactory, Extension Schema) This is the proposed API, with detailed comments explaining use. IDetailPane.java - API to create the pane and display selections in it IDetailPaneFactory.java - API to create IDetailPanes and load from extension point detailPaneFactories.exsd - Schema file describing the extension point Please comment with issues and concerns.
Created attachment 54752 [details] Screenshot of proposed UI Screenshot how the new menu might look. It uses a radio button style so that the current detail pane type is marked. Currently the Show details as menu option is displayed even if there is only one possible option (this differs from the logical structures menu). Any comments?
The menu approach looks good. To tie this in with how we've done the GUI-rich register details in our product, we would have a special composite that has our various sections within it. We need the ability to show multiple sections simulataneously.
Created attachment 55071 [details] Patch for review This patch contains the completed changes to debug UI. Waiting for review by debug committers so it can be added to HEAD. Two small changes to the API attached previously. A setFocus() method was added to IDetailPane so that detail panes containing multiple widgets can persist which widget had focus previously. In addition, the display is now expected to handle null or empty selections (they should clear the pane).
Created attachment 55074 [details] Patch with changes to debug help This patch contains my changes to the debug help documentation (org.eclipse.jdt.doc.user). I added one image ref-detail_pane_context_menu.PNG which shows the menu used to select between different panes. I also renamed and moved reference/views/shared/images/ref-detailpane_dialog.PNG to reference/detail_pane/images/ref-max_length_dialog.PNG. The image changes are not reflected in the patch and must be done manually. I will attach the new image right after this.
Created attachment 55075 [details] New image for help showing context menu
One other thing, some changes included in the patch should not be added to HEAD. TableDetailPane.java, TableDetailPaneFactory.java and the "Table Detail Pane Factory" extension in plugin.xml were used for testing and are not intended to be added to HEAD. The table detail pane is useful for testing the API, enablement expressions, and the effects of using composites. It creates a composite in the detail pane and adds a table, a text and a check box action.
Released to HEAD with some doc changes and javadoc updates. Still need to release help documentation and update doc plug-ins for new extension point. Curtis, please create a patch against HEAD to *not* re-use detail panes across dispose/re-creates. Once a pane is disposed, it should be thrown out.
Released help with minor modifications.
Created attachment 55154 [details] Patch that fixes detail pane proxy to not reuse panes after disposal Only changes DetailPaneProxy.java. A new detail pane is instantiated each time the pane changes types (old one is disposed, new one is instantiated, initiated, and asked to create a control).
Marking fixed for M4. Will open new bugs as required.
Verified.
Created attachment 55797 [details] Example Pane Project This zip file contains a plugin project that adds a new detail pane called Table Detail Pane. The pane is a composite containing a table, a text box and a check box action. The code is not very robust, but it does provide some ideas how to create a detail pane. In case it wasn't clear, the pluggable detail pane feature was merged with HEAD on December 6th, and is available in 3.3 builds after that date.
I've reviewed and prototyped against the APIs in 3.3 M4. The support meets our needs, with one exception. We want the ability to add a details pane to one view but not another. The enablement criteria in the extension definition allows for filtering on the selected element runtime type, but such a criteria can be inadequate when dealing with views whose elements derive from each other in the model. As it turns out, this is the case for the Register, Variables and Expressions view. For example, IRegister derives from IVariable, and the corresponding implementation classes in CDT follow the same pattern (CRegister derives from CVariable). As such, a check of (element instance of CVariable) would hold true for both the Variable and Register view. This makes it problematic to contribute a pane to the Variables view but not the Registers one. Also, I would like to recommend that the Javadoc be enhanced to publicize that IDetailPaneFactorry.getDetailsPaneName(ID) should return the same as IDetailPaneFactory.createDetailPane(ID).getName(). IDetailPaneFactorry.getDetailsPaneDescription(ID) should return the same as IDetailPaneFactory.createDetailPane(ID).getDescription(). IDetailPaneFactory.createDetailPane(SOMEID).getID() should return SOMEID. The above expected equalities highlight some redundancy in the APIs. I’ve been told the redundancy exists for the sake of performance. That’s fine but the redundancy can lead to confusion; so, if it is to stand, stating the above equalities in the javadoc will help reduce some head scratching.
Created attachment 57925 [details] Tests for detail pane This patch adds tests for DetailPaneManager. It also makes one fix to prevent an NPE. The manifest change the patch makes was added to head not long ago, so that change can be ignored if you are using a recent build.
Reopened to commit tests
Tests have been released.
