[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-ui-dev] Re: [platform-debug-dev] Presentation of "Execution Location" in editors
|
Making the debug model presentation responsible seems to be good even
independent from the attempt to achieve a better indication of the current
execution location. I am not in favor of giving the editor any awareness of
the debugger at least not on the level of Platform. Right now Platform UI
is independent from Debug Core/UI . JDT UI depends on Debug Core/UI but is
independent from JDT Debug. The dependency of JDT UI from Debug Core/UI is
minor with the exception of the JavaDoc generation process. I think these
dependencies should be kept minimal and not be extended.
The debug model presentation should use public editor API. In general
this is just gotoMarker on IEditorPart. Text editors could provide API that
allows to achieve a better indication of the current execution location. A
premature thought is adding custom annotations to the annotation model of
the editor's input element and adding a custom painter for styling (e.g.,
the background color) the annotation range. This requires new API on the
editor side. To which degree this mechanism should be coupled I don't know
yet. Probably it would be useful to provide extension points for custom
annotations and custom painters coupled to marker types. This would be a
generalization of how problem markers are presented currently.
One issue I see is that editors are shared between the different
perspectives of one workbench window. This means that if the current
execution location is displayed using, e.g., a different background color,
this indication is visible even if the user switches from the debug
perspective into another perspective. This is the same also for custom made
perspectives. For example, my favorite style of working is to switch away
from the debug perspective to "forget about debugging" independent of
whether the debug session is over or not. I'd perceive a sticky indication
as too disruptive especially when simultaneously being displayed together
with the current line highlighting. How do others solve this context
problem?
Kai
"Darin Wright"
<Darin_Wright@oti To: platform-debug-dev@xxxxxxxxxxx
.com> cc: jdt-ui-dev@xxxxxxxxxxx
Sent by: Subject: [jdt-ui-dev] Re: [platform-debug-dev] Presentation of "Execution Location" in
jdt-ui-dev-admin@ editors
eclipse.org
09/03/2002 06:12
PM
Please respond to
jdt-ui-dev
I'm cross posting this to JDT-UI for comments.
Darin
"Joe Szurszewski"
<Joe_Szurszewski@xxxxxxx> To:
platform-debug-dev@xxxxxxxxxxx
Sent by: cc:
platform-debug-dev-admin@ Subject: Re:
eclipse.org [platform-debug-dev] Presentation of
"Execution Location" in editors
09/03/2002 09:37 AM
Please respond to
platform-debug-dev
I like this plan a lot. Losing selection, and thus any indication of the
current line has always been annoying. I vote for making this part of the
debug model presentation, since the pluggability of presentations would
make it easier for an implementor to change just the instruction pointer
behavior. If this lived in the editor, debug model implementors would have
a harder time changing this behavior.
Joe
"Darin Wright"
<Darin_Wright@xxxxxxx> To:
Sent by: platform-debug-dev@xxxxxxxxxxx
platform-debug-dev-admin@e cc:
clipse.org Subject: [platform-debug-dev]
Presentation of "Execution Location" in
editors
08/30/2002 11:13 AM
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
