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:
- 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.
- 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
- Open the breakpoint view menu and select "Working Sets..."
- New dialog opens.
- Selection "New..."
- A wizard opens.
- Select "Breakpoints", click Next
- Think of a name and type it in
- 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.
|