Difference between revisions of "DSDP/DD/MultiContext UnlinkViewContextProposal"

Revision as of 22:56, 10 September 2007

Overview

This is a proposal to change the workflow of selecting the context for data displayed in the standard debug views. These views include: Variables, Registers, Expressions, Memory, and possibly the Console views. This proposal builds on the previous efforts to improve multi-context debugging workflow: bug 145635 (Support for debug view pin & clone).

Goals

• Allow user to switch the active context of a debug view without leaving the view.
• Allow user to switch the active context of a debug view and without having to have the Launch view visible.
• Allow user to have multiple instances of debug views open and showing data from different contexts side-by-side.
• Avoid breaking any established UI paradigms with respect to views' interaction.

New UI Components and Workflow changes

Debug context selection dialog

A new selection dialog would allow user to choose the input context of a debug view. When the debug context selection dialog would open it would show a tree viewer where the top nodes are the participating debug context providers, and the sub-trees under the providers would be the contexts available for selection. Platform will provide the Launch Manager as the standard debug context provider, but others, such as Target Manager could also be shown. User would select the desired context in the dialog and press OK, to set the new input context to the view.

The debug context selection dialog should have a dedicated key binding and a tool-bar button or view menu item.

Link button

The standard debug views should all have a link toggle button on their toolbars. If the link button is down (default), the view context should follow the active window debug context as is does currently. If the link button is up, the input context of the debug the view should not change unless explicitly changed by the user. Selecting a new context using the debug context selection dialog would automatically un-link the view from window selection.

View content description

With the debug views able to select their own input context and with the Launch view possibly hidden or absent, it may be difficult to determine what is the current context of a given debug view. To address this problem, the content description of the view should be activated whenever a debug view is showing contents from a context that is different from the currently selected window context.

The content description of a view is currently limited to showing only text. To make it more useful for this feature, it should be extended to show an icon as well.

Multiple view instances

Standard debug views should be configured to allow multiple instances of views to be opened. A toolbar button (or view menu item) should be added to easily open a new instance of the view. The memory view already supports this feature.

APIs

New context event: DebugContextEvent.CONTENT

In this feature proposal, views are be able to keep a given context as input even after that context is no longer active with a provider. The implication of this is that a given debug view can have an input context configured, which eventually gets terminated, removed, or otherwise becomes invalid. In this case, the debug view needs to be able to able to discover when a given context becomes invalid and change its input context as to avoid displaying stale data.

To facilitate this, the debug context providers should issue DebugContextEvent.STATE events for any context monitored by the given provider, not just for the active context. Also, the providers should issue a DebugContextEvent.CONTENT event whenever a sub-tree of a model changes in the given provider. The view can listen to these events and update as necessary.

IDebugContextProvider.getPresentationContext()

In a situation when:

1. a debug view is un-linked from a provider,
2. and it its input context is set to a given element which came from a given provider,
3. the input context becomes invalid due to a DebugContextEvent.CONTENT event,

the debug view should be able to use the IElementMementoProvider of the input context elements in order to find and select a new context, which is equivalent (has the same memento) to the one that became invalid. This would be useful, for example, to keep focused on a stack frame while stepping.

In order to implement this, the debug context provider should have a method to retrieve the IPresentationContext used by the provider, so that the debug view may construct IElementMenentoProvider requests properly.

Debug context selection dialog

Debug context mechanism allows for multiple context providers to be present, which are registered with the IDebugContextService.addContextProvider() call. However, the debug selection dialog should be able to operate even if the debug view and other debug context providers are not open. To address this, a new interface will be needed:

public interface IDebugContextRoot {
    Object getRootElement();
}

To allow the lazy loading of IDebugContextRoot implementations, an extension point should also be provided to register context roots. When the context selection dialog is first opened the context root would be instantiated.

The root element returned by getRootElement() could then be used in the selection dialog to populate the contents of the dialog using the flexible hierarchy APIs (IElementContentProvider). After a selection is made in the dialog to set a view context, the debug view will need to install a IModelProxy on the root element of the context root and any children in order to generate proper debug context events. Registering model procies will allow the view to detect when the selected input context becomes invalid.

Alternative Design

One problem with the above design is that flexible hierarchy adapters for the elements originating from getRootElement() would need to support a new presentation context, coming from the selection dialog. This would mean a wide sweeping change to the existing model adapters.

To address this, the Debug context selection dialog could be split into two parts:

1. A drop-down selection control allowing user to choose the IDebugContextRoot
2. A tree viewer with the elements' hierarchy.

Another method would be added to the IDebugContextRoot: IPresentationContext getPresentationContext().

This design also has the added advantage in that the extension points providing IDebugContextRoot would not have to be invoked until the user chose the given root in the drop down.

IDebugContextService behavior changes

The standard debug views are listeners to the events coming from the window debug context service. Besides the input into the view, the active context returned by context service is used by actions which are contributed to the debug views. To control their context, debug views need to register their own providers with the window service using the IDebugContextService.addDebugContextProvider() method. View context listeners (e.g. view actions) can register themselves as listeners to context events using addDebugContextListener(IDebugContextListener listener, String partId). However, currently listeners registered this way will not receive any events if there is no provider registered for that ID. Since the views need to change between having their own provider and listening to the window context, I propose the following change to the debug context service:

• Listeners registered using addDebugContextListener(IDebugContextListener listener, String partId) should receive active window context events if there is no provider registered with the given ID.