|[platform-debug-dev] ideas for improving multi-context debugging|
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.
Allow user to "unlink" debugger views and the change their input debug contextThis 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:
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
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:
Multiple instances and linking for Debug view tooThe 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.