[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-debug-dev] Presentation of "Execution Location" in editors
|
I think this is a great idea. Current behaviour of loosing this selection
once in the editor is more
then just annoying.
I think that debug model really should be implementing the
IExecutionLocationPresentation since
it will be then consistent across all the editors that are used by this
model.
Regards,
Vadim Berestetsky
Distributed Debugger Development
Phone (905) 413-4403; T/L 969-4403
Internet: berestet@xxxxxxxxxx
"Darin Wright"
<Darin_Wright@xxxxxxx> To: platform-debug-dev@xxxxxxxxxxx
Sent by: cc:
platform-debug-dev-admin@ Subject: [platform-debug-dev] Presentation of "Execution Location" in editors
eclipse.org
08/30/2002 12:13 PM
Please respond to
platform-debug-dev
Following is a proposal for displaying a program's execution location
(instruction pointer) in editors. (Related bug -
http://bugs.eclipse.org/bugs/show_bug.cgi?id=1524).
Currently the (generic) debug UI displays the current execution location by
selecting the line associated with the selected stack frame. This approach
has a couple of problems:
* The selection is lost if the user clicks in an editor
* The implementation uses an IMarker, and assumes the editor is a text
editor
To improve this, I suggest that the debug UI define a new interface which
either an editor or a debug model presentation could implement (not sure
which is best). The interface would be called something like
"IExecutionLocationPresentation", and would define the following methods.
(If the model presentation were the implementor, instead of the editor, the
editor would also be passed along as a parameter)
* showExecutionLocation(IStackFrame)
* clearExecutionLocation()
The Debug UI would call these methods to display the current execution
location as a program under debug suspends/resumes. It would be up to the
implementation to determine how the location is rendered, and this API does
not limit the presentation to text editors. If a presentation/editor did
not implement this interface, the current method of presentation would be
used - i.e. line selection.
One benefit of having the debug model presentation responsibe for the
execution location presentation is that an editor would not have to be
aware of the debugger (although, it might want to be, to allow access to
the internals of the editor to produce a better presentation).
Comments welcome.
Darin
