Re: [platform-debug-dev] debug view features for embedded debugging

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

> 
> 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).

> 
> 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)?

> 
> 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.

> 
> 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,

Darin