[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-debug-dev] debug view features for embedded debugging
|
Darin Wright wrote:
1. A "double-click to open editor" preference option. Currently the
debug view opens the editor for selected stack frame on every selection
change, and conversly, on every suspended event. This is desirable most
of the time, but in certain situations, like when running scripts, this
can be very disruptive. It makes editing impossible and working with
some views annoying, because when the debugger opens an editor,
maximized viewa are un-maximized. We would like to add a mode where the
user has to double-click a stack frame in order to open the editor.
This sort of preference sounds reasonable, and would be easy to implement.
However, how should stack frame selection effect other views when the
"double-click" preference is on. For example, the variable view updates
its contents based on stack frame selection. Would only source lookup be
effected, or are you suggesting that other dependant views would only be
updated on double-click as well (which, I feel, would be less
desirable/too confusing).
In our implementation the selection event is still sent, so no
inconsistency there. In our debugger, the user can drive the debugger
(and generate debug events) from a command-line interface, which is best
viewed maximized.
So the really offending part is the editor being opened and/or raised to
the front, because that causes the frame manager to un-maximize the
current view.
I'll file a bug on it and include my patches... although I might wait a
little as I'm still working out a few bugs in it.
2. DebugEvent.SUSPEND_RESUME event. In embedded debuggers especially
retrieving and displaying data can be very expensive, especially when
user is stepping and is only interested in seeing the IP move on the
screen. To address this, we would like to add a debug event that would
only be intended for the debug view, in order to update the IP
annotations. I haven't fully thought through what other implications
this might have so another method (rather than new event) of achieving
the same ends might be more appropriate.
Events are intended to describe what is happening in the debug model,
rather than be used directly as UI flags. Thus, I would prefer to see a
different solution. Perhaps this means that the debug view should simply
have a mode where it does not broadcast selection changes (which drives
other views, such as the variables view)?
separate email
3. Preference option to retrieve only one, or fixed set of stack frames
on a suspended event. Retrieving a full stack trace can be very time
consuming, and is often not necessary. We would like to add a mode
where the debug view only shows the top frame, or a limited number of
frames, then it shows the full stack trace when requested by the user.
It is possible implement this feature without modifying the debug view
at all, but it's not particularly clean.
A similar request has been submitted:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75960. Please add any
requirements to this bug report.
Great, I'll use that to submit my patches... when I have them. :-)
4. Multiple selection spaces in debug view. The purpose of this is to
make it easier to debug multiple processes, threads, etc, at the same
time. This is a very wide-reaching feature, but the basic idea is to
have multiple selections being maintained by the debug view, and have
other views (expression, registers, memory, etc) listen only to one of
the selections. This also implies having multiple instances of these
views. In our case we differenciate the selection spaces by color, so
we paint all the debug elements of the same selection space and the
views listening to it, all the same color . Once again, we have
implemented this without modifying the debug view, but it is not very
clean, and there's some features that we simply cannot make work.
This is a difficult one :-) It will need some thought/investigation. The
main technical issue is that the debug view selection drives other views
(variables, expressions, evaluation contenxt for editors, etc.), and we
would need a clean way to link downstream views with the appropriate
selections. A good place to start would be to submit a description of how
this could work, from the user point of view.
Thanks,
Since you sound receptive, I'll file a bug on with a more detailed
description, screen-shots etc. so we can have a meaningful discussion on it.
Darin
Thanks!
Pawel
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
