[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [dsdp-dd-dev] Multicontext debugging proposal
|
Good timing! I was just about to start prototyping this proposal.
Darin Wright wrote:
Hi Pawel,
I added more comments to the multicontext debugging proposal:
http://wiki.eclipse.org/DSDP/DD/MultiContext_UnlinkViewContextProposal#Comments
Since the comments section is getting large I've also included them in
this posting:
I'm having serious doubts about using a wiki for raw comments. For
future reference, I think it'd be better to hold the discussion in the
email thread and use wiki to summarize them.
Reviewing this proposal again, I think what's missing is the higher level
goal. I believe the higher level goal is to be able to have sets of debug
views linked to a specific context, and to be able to have different debug
contexts (e.g. cores within a session) have different sets of views that
can be placed side by side.
I think a problem with this proposal is that it places a heavy burder on
the user to manage views. For example, they must manually unlink and pin
views to a specific context. Then, once a context is stale it's not clear
how to cleanup the view (i.e. is it left floating?), and how to
capture/reuse a "view configuration" in a later debug session now that
time has been spent setting it up. Can the user set up a view
configuration before launching (i.e. in a launch configuration)?
I agree that on its own these changes would add complexity to the UI
without giving the user any new tools to manage this complexity. I was
planning to follow up these changes with a second proposal which would
add some form of "debug working sets" to manage this added complexity.
I thought it would be a lot easier to think about that proposal with a
working prototype in hand though.
However, I also hope that adding these features to the UI could stand on
its own, to avoid having to accept or reject a huge set of UI changes
all at once.
Note that the debug platform already has a mechanism for grouping views
for a particular kind of debug session. For example, a Java debug session
has a certain set of views assocaited with it, and when the user selects a
Java stack frame, the relevant views are brought to the front/opened.
There are extension points to support this: contextViewBindings and
debugModelContextBindings. Basically, we tie a "context" to a set of views
and bind a debug model to a "context".
I wonder if it would be simpler to enhance the existing support to allow
for a "new set" (more instances) of the same views to be opened for a
debug session. This would leverage the existing support any may help
achieve the higher level goal (a dedicated group of related views for a
debug session) with less steps/burden placed on the user. I could also see
this sort of support appearing in a launch config - i.e. as a check box to
use a new set of views, and perhaps which views they'd like to see.
I think leveraging the existing view to context bindings is a good idea,
but IMO just relying on this mechanism alone would be too restrictive.
As far as the launch configuration UI, I have to admit I'm somewhat
prejudiced against configuring view layout through a modal dialog, it
seems distant and detached from the actual problem. I would rather be
able to open and lay out my views, and then have the debugger magically
remember this information for me. Part of that magic may be to
serialize layout information using the launch configuration (among other
parameters) as the key.
I'm glad you are still thinking about this problem and I hope you have
time to keep this discussion going. I would like to go for it and
implement the prototype over the next couple of weeks, and then
hopefully we'll be able to talk about these changes in a less
theoretical context :-)
Cheers
Pawel
Darin Wright
Eclipse Debug Lead,
Rational Team,
IBM Canada
(204)938-8051
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev