Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-debug-dev] 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

Back to the top