[platform-debug-dev] ideas for improving multi-context debugging

[Pawel Piech <pawel.piech@xxxxxxxxxxxxx>]

Hi All,
With Europa behind us, hopefully it's not too late to start talking about platform features in the next release :-) 

After I recently spent a few long weeks implementing a pin-and-clone feature in debugger views in our commercial incarnation of Eclipse, which felt a lot like pounding a square peg into a round hole, I did some soul searching on the whole paradigm of multi-context (multi-core) debuggung.  I finally realized, that while we were extending a lot of effort to allow the user to see more data, a typical user has the opposite problem, where there is too much data on the screen already for him to be able to use it efficiently.  After thinking of how we could allow the user to better focus on the data relevant to his task, and then to allow him to manage multiple tasks simultaneously, I came up with the following features.  None of these are very revolutionary, but hopefully that means that  they have a better chance of being adopted.

Also, I apologize that this is not a formal proposal with use cases, definitions of terms and such.  But with very limited time on my hands I thought it was more important to get the discussion started and try to just clarify questions as they arise.

Cheers
Pawel

---

Allow user to "unlink" debugger views and the change their input debug context

This is another way of thinking about the Pin+Clone functionality.  Pinning, as it's been pointed out, is a concept that is used rather inconsistently in various views.  For example, in the console view, it means don't switch to a different debug context, but in the search view it means "open a new view instance for next search", in the memory view it means something different still.  So instead of pinning we could use the concept of linking the view to the active debug context.  This concept is well established, and its even already used in the Breakpoints view.

When the link button is depressed, which is the default, the debugger views (variables, registers, _expression_, memory, and console) will follow the current selection in the window, which in turn would usually come from the Debug view. 

When the link button is not depressed, a content description in the view would indicate the current focus of the view.  And a second toolbar button would be enabled which would allow the user to select the input context for the view.  There are two challenges here:

1. The content description for a view is currently pretty drab, i.e. there is no icon and there is no tooltip to show the full string in case the view port is too small to fit it. 
   
2. The UI for the view input selection would need to be well thought out and polished.  IMO, a tree-based selection dialog with filtering would probably be best. 
   

Create a dedicated source viewer "editor" which will also be able to change the input debug context (no platform changes needed).

Changing the input debug context from within the variables (and other debug views) will eliminate one pain point: being able to jump between stack frames, threads, etc, without switching views and with only a couple of key strokes.  But the same problem exists in the editor/source viewer.  During typical debugging workflow user is forced to exit the source viewer and go to the debug view, in order to switch to a different stack frame or thread.  This is similar to being forced to go the the package explorer in order to switch to open another file. 

Unfortunately an a single editor, which is opened to a particular source file, could be simultaneously "focused" on multiple debug contexts.  And it is not easy to translate selection in the editor to a debug context selection. 

A simple solution to this problem is to create a dedicated "source viewer" editor which has an explicit focus on a given debug context and which is also a debug context provider so it can drive the active window debug context.  Actually, we should be able to achieve this with the current APIs, so no new platform features would be needed).

Create a "Debug" working set, extending the current concept of "Breakpoint" working set.

The biggest obstacle to working efficiently with the debugger is the constant need to browse through heaps of information: threads, stack frames, variables, breakpoints, to get to the ones that are relevant to the problem.  The obvious solution to this problem is to extend the idea of working sets to debugging. 

The problem with the working sets is that they are fairly static and they require quite a bit of work on users part to set up.  For example to create a breakpoint working set, the user has to

1. Open the breakpoint view menu and select "Working Sets..."
2. New dialog opens.
3. Selection "New..."
   
4. A wizard opens.
5. Select "Breakpoints", click Next
   
6. Think of a name and type it in
7. Click the check box for each breakpoint to be included in the breakpoint (fortunately, once the working set is created, and the view is configured to show it, users can drag and drop new breakpoints into it).
   

Although this may be acceptable for project working sets, which the user tends to create once for the lifetime of the workspace, it is not acceptable for debugging because each problem and even each step in solving a problem usually requires its own set of breakpoints.  So it should be possible to multi-select a few threads, right click on them and select "Create new working set..." to get a dialog with all values filled in.

However, the real problem with creating "Debug" working set is in the fact that most debug elements lifecycle is relatively short: threads/processes live for the duration of a debug session, stack frames, variables, etc., have an even shorter life span.  So in order for these working sets to work, it has to be possible to optionally use element mementos and/or filters in order to get the desired elements in the set.

Debug working sets could be used to narrow the focus in debugger views in the following ways:

• Select launch configurations, processes and threads in Debug view to a working set.
• Select variables and registers to a working set, where the selection takes into account the context of the variable.  I.e. which stack frame, thread, etc, the variable was in.
• For variables views that listen to the active debug context, the active working set would act as a filter.  So that if a variable view has an active working set with threads x, y in it, and thread z is selected, the view input will not change.
  
• Select memory blocks.
  
• Select breakpoints to a set (already implemented)
• Also for breakpoints which are being installed on the target, the process/thread filter setting in that working set can be used to determine whether the breakpoint is applicable to that target, and which threads it is applicable to.

Finally, active working set should be a little more visible in the UI.  Currently, when a working set is set to the Package Explorer view, there is no visible change in the view except for the list of visible projects.  Once again this is acceptable for projects, but for the debugger where the working sets need to be more dynamic and multiple instances of views could be opened focused on different working sets, there needs to be some indication in the view of what is the active working set, as well as when tabbing through views with keyboard shortcuts.  Once again, the view content description comes to mind.

Multiple instances and linking for Debug view too

The debug view should also allow for multiple instances, but more importantly, it should be deemphasized somewhat as the center of debugging activity in Eclipse.  The Debug view is primarily used to navigate between threads and stack frames, and for controlling the execution state of the debugger.  For general debugging, the former is needed some of the time, but the latter is needed pretty much all the time.  When screen real estate is an issue, it seems unfortunate to have to use a large portion of it for displaying data that is not always critical.

To address this problem I would suggest to remove the debug run control buttons from the Debug view, and put them on the global tool bar.  This would free up some room in the crowded Debug view toolbar, and it's where most of new Eclipse users these buttons to be anyway.  I haven't looked for it in bugzilla, but I suspect that there must have been some religious battle about this issue in the 1.x or 2.x releases. 

Finally we should allow for multiple instances of Debug view, so that some can have an active debug set configured and so users could debug things side by side, and we should add a "link" button to Debug view as well, so that it could also track the active debug selection if it changes as a result of user action in the source viewer or another view capable of driving window selection.