Skip to main content

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.

Jump to: navigation, search

Special viewer for both components

Revision as of 20:48, 2 January 2008 by Pawel.piech.windriver.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The Viewer Model


The proposed viewer implementation is based on the SourceViewer and Document classes. Both classes are extended to support the model that consists of the following elements:


Root: maps to the current disassembly context.


Current Base: an object that represents the starting point of the disassembly presentation. It is calculated from the current debug context or underlying memory block (in case of the memory rendering). The client provided content adapters are responsible for this conversion.


Line: represents a line in the disassembly presentation. Depending on the backend model it can be a disassembly instruction, source line, label, etc. Lines are referred by the offset (positive or negative) from the current base element.


For example, for the CDI based models, the IDisassembly objects can be mapped to the root elements, the IDisassemblyBlock objects to base elements and the IASMSourceLine and IASMInstruction objects to line elements.


How It Works


The document associated with the viewer provides the textual content and is responsible for the conversion of the model elements into the text presentation and vice versa. The viewer notifies the document when it is refreshed, scrolled or resized. The document generates content requests to the content provider based on the number of lines required and their offsets from the base element. The content provider uses content adapters contributed by clients to get the “real” content. When the content is received the content provider requests the labels and annotations for each line. Label and annotation adapters are also contributed by clients. The content provider also maintains the set of the model proxies required to convert the backend model notifications into the viewer updates. Clients can provide model proxy adapters for these purposes. All content adapter calls include the presentation context as a parameter.


Example

1. A stack frame is selected in the Debug view. As a result the “setInput” method of the viewer is called.
2. The viewer informs the document that the current input is changed.
3. The document requests the base element update from the content provider.,
4. The content provider passes the request to the content adapter. If the current base element is not valid anymore the content adapter provides a new base element and the full content update is required. If the base element remains the same, the annotation request is issued to update the instruction pointer positions.



Classes


Following is the description of the main classes and interfaces required for these proposals.


DisassemblyEditor

Description:
Provides the underlying viewer with input. Listens to the debug context changes and converts the current debug context into an input.


DisassemblyMemoryRendering

Description:
Extends AbstractMemoryRendering. Provides the underlying viewer with input.


DisassemblyPane

Description:
Used in the control part of DisassemblyEditor and DisassemblyMemoryRendering. Contains the editor specific classes common for both parents.


VirtualSourceViewer

Description:
Used in the control part of DisassemblyPane. Extends SourceViewer. Notifies the associated document when the viewer is refreshed, scrolled or resized.


VirtualDocument

Description:
Extends Document. Converts the model elements into the text content.


DocumentContentProvider

Description:
Manages the mapping between the viewer model and the underlying debug model through the content, label and annotation adapters. Maintains the list of model proxies and reacts to the debug model changes.


DocumentLabelProvider

Description:
Responsible for the label updates.


DocumentAnnotationProvider

Description:
Responsible for the annotation updates.


The clients are required to implement the following interfaces:

IDocumentElementContentProvider
IDocumentElementLabelProvider
IDocumentElementAnnotationProvider
IModelProxy

Back to the top