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.
Difference between revisions of "DSDP/DD/MultiContext UnlinkViewContextProposal"
| Line 1: | Line 1: | ||
== Overview == | == Overview == | ||
| − | This is a proposal to change the workflow of selecting the context for data displayed in standard debug views. | + | 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: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=145635 bug 145635 (Support for debug view pin & clone)]. |
== Goals == | == Goals == | ||
| Line 16: | Line 16: | ||
=== Link button === | === 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 follows the active debug context as is does currently. If the link button is up, the input context into the view does not change unless it is explicitly changed by the user with the input selection dialog. | + | The standard debug views should all have a link toggle button on their toolbars. If the link button is down (default), the view context follows the active debug context as is does currently. If the link button is up, the input context into the view does not change unless it is explicitly changed by the user with the input selection dialog. Selecting a new context using the Debug context selection dialog automatically un-links the view from window selection. |
=== View content description === | === View content description === | ||
| Line 27: | Line 27: | ||
== APIs == | == APIs == | ||
| + | |||
| + | === New context event: <code>DebugContextEvent.CONTENT</code> | ||
| + | In this feature, views are be able to keep a given context as input even after that context is no longer active with a provider. This has a major implication in that the views still need to be able to determine when a given context becomes invalid, so that they no longer display stale data. To facilitate this, the debug context providers should issue <code>DebugContextEvent.STATE</code> events for any context monitored by the given provider, not just for the active context. Also, the providers should issue a <code>DebugContextEvent.CONTENT</code> 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: | ||
| + | # a debug view is un-linked from a provider, | ||
| + | # and it its input context is set to a given element which came from a given provider, | ||
| + | # the input context becomes invalid due to a <code>DebugContextEvent.CONTENT</code> event, | ||
| + | the debug view should be able to use the IElementMementoProvider of the input context elements, in order to find and select an equivalent context 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 <code>IPresentationContext</code> used by the provider, so that the debug view may construct IElementMenentoProvider requests properly. | ||
=== Debug context selection dialog === | === Debug context selection dialog === | ||
| Line 37: | Line 49: | ||
To allow the lazy loading of <code>IDebugContextRoot</code> 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. | To allow the lazy loading of <code>IDebugContextRoot</code> 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 <code>getRootElement()</code> can then be used in the selection dialog to populate the contents of the dialog using the flexible hierarchy APIs (<code>IElementContentProvider</code>). | + | The root element returned by <code>getRootElement()</code> can then be used in the selection dialog to populate the contents of the dialog using the flexible hierarchy APIs (<code>IElementContentProvider</code>). After a selection is made in the dialog, the input context is set to the view, and the dialog is closed, the debug view will need to install a <code>IModelProxy</code> on the root element of the context root, and any children, in order to generate proper debug context events, and to decect when the selected input context becomes invalid. |
==== Alternative Design ==== | ==== Alternative Design ==== | ||
| Line 53: | Line 65: | ||
<code>IDebugContextService</code> has the <code>addDebugContextProvider()</code> method which should allow the view to specify its own provider when it is not listening to the active provider. Also, listeners (actions) can register themselves as listeners to events using <code>addDebugContextListener(IDebugContextListener listener, String partId)</code>. However, listeners registered this way will not receive any events if there is no provider registered for that ID. I propose the following change: | <code>IDebugContextService</code> has the <code>addDebugContextProvider()</code> method which should allow the view to specify its own provider when it is not listening to the active provider. Also, listeners (actions) can register themselves as listeners to events using <code>addDebugContextListener(IDebugContextListener listener, String partId)</code>. However, listeners registered this way will not receive any events if there is no provider registered for that ID. I propose the following change: | ||
* Listeners registered using <code>addDebugContextListener(IDebugContextListener listener, String partId)</code> should receive active window context events if there is no provider registered with the given ID. | * Listeners registered using <code>addDebugContextListener(IDebugContextListener listener, String partId)</code> should receive active window context events if there is no provider registered with the given ID. | ||
| − | |||
| − | |||
Revision as of 13:03, 8 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
- To make it possible to switch the active context of a debug view without exiting the view.
- To make it possible to switch the active context of a debug view and without having to have the Launch view visible.
- To make it possible to have multiple instances of debug views open and showing data from different contexts side-by-side.
- To avoid violating any established UI paradigms with respect to views' interaction.
New UI Components and Workflow changes
Debug context selection dialog
A modal new selection dialog would allow user to choose the input context. When the debug context selection dialog is opened it shows a tree viewer where the top nodes are the participating debug context providers. Platform will provide the Launch Manager as the standard debug context provider, but others, such as Target Manager could also be shown. User can select the desired context in the dialog and press OK.
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 follows the active debug context as is does currently. If the link button is up, the input context into the view does not change unless it is explicitly changed by the user with the input selection dialog. Selecting a new context using the Debug context selection dialog automatically un-links 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 actually 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 rather limited in that it is only capable of showing text. To make it more useful for this feature, it should be extended to provide 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, views are be able to keep a given context as input even after that context is no longer active with a provider. This has a major implication in that the views still need to be able to determine when a given context becomes invalid, so that they no longer display 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:
- a debug view is un-linked from a provider,
- and it its input context is set to a given element which came from a given provider,
- the input context becomes invalid due to a
DebugContextEvent.CONTENTevent,
the debug view should be able to use the IElementMementoProvider of the input context elements, in order to find and select an equivalent context 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. Therefore a new interface is 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() can 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, the input context is set to the view, and the dialog is closed, 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, and to decect when the selected input context becomes invalid.
Alternative Design
One problem with the above design is that IElementContentProvider implementations for the elements returned in a hierarchy under the element returned by getRootElement, would need to support the IPresentationContext from the selection dialog. With the current implementation of the standard debug model content providers and model proxies, this could be a big problem.
To address this, the Debug context selection dialog could be split into two parts:
- A drop-down selection control allowing user to choose the
IDebugContextRoot - 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 extensions
The standard debug views are listeners to the events coming from the context service for the given window which they are in. Besides the input into the view, the active context returned by context service is used by actions which are contributed to the debug views. If the standard debug views are to be able to change their active context, they need a way of notifying the context service of the active context in the view so that the view actions are in sync.
IDebugContextService has the addDebugContextProvider() method which should allow the view to specify its own provider when it is not listening to the active provider. Also, listeners (actions) can register themselves as listeners to events using addDebugContextListener(IDebugContextListener listener, String partId). However, listeners registered this way will not receive any events if there is no provider registered for that ID. I propose the following change:
- Listeners registered using
addDebugContextListener(IDebugContextListener listener, String partId)should receive active window context events if there is no provider registered with the given ID.