Re: De-centralization of the Launch View
The proposal suggested that a default context provider is created for a
window. The default context provider is not tied to any view. The Launch
View is simply a listener to the default context provider. This allows the
Debug Perspective to operate without the presence of the Launch View. The
concern here is that without having a view tied to the default context
provider, it is extremely confusing to figure out what the current debug
context is. I agree that having another "kind" of view to drive the active
debug context is a good idea, but not having a view at all can cause
usability problems. For example, if the user is debugging a multi-threaded
application, and the user is suspended at Thread A, and debugging.
Meanwhile, another thread, Thread B, is suspended. Without a view to
indicate that something else is suspended, how does the user know that
another context has become available? What are some of the reasons why we
do not want a view to drive the active debug context? Why is having a view
opened to drive the current context problematic?
The launch view takes up a lot of screen real estate: it needs to be
wide enough to fit the long labels of stack frames, and it needs to be
at least high enough to show all the levels in the tree (since a stack
frame is 4 levels deep). As a user I try to configure my view layout
to have as much screen dedicated for the editor as I can, even on a
1900x1200 screen... maybe it's a bit of an obsession but I'm probably
not alone :-) What's frustrating to me about the Launch view is that
most of the time I actually don't care about the data that's in it,
because as a plugin developer I usually run one program at a time, I
can figure out what thread I'm in based on the code that is executing
and I mostly look at the top stack frame.
Re: Global Debug Actions Toolbar
Since the Launch View does not need to be present all the time, actions
from the Launch View's toolbar need to become global. This causes a couple
problems for us:
- Real-estate on the global toolbar - this makes the global toolbar more
cluttered.
- When invoking action on the toolbar, how does the user know what context
the action is invoked on. e.g. if I press resume, which thread am I
resuming, without having the Launch View tells me which thread is in focus?
We also believe that this is a side effect to not having a view to drive
debug context. If a view is always present, then there will be no need for
global debug actions toolbar.
True, having a global toolbar is primarily intended to allow Launch
view-less debugging. Ironically enough though, in our product we have
the opposite toolbar real-estate problem. We have too many buttons in
the Launch view itself.
Re: Changes in behavior with addDebugContextListener(IDebugContextListener
listener, String partId)
If the client has registered with a partID that does not exist, the
proposal is to change the behavior to have the listener get a context
events from the default context provider. In my opinion, when the client
has specified a part id with the listener registration, the client intends
to filter out events from views that it does not care about. Otherwise, the
client could have registered without the part id. Changing this behavior
could break existing clients and introduce compatibility issues.
This could be an ugly problem for implementing these changes.. the
alternative would be to add a whole bunch of duplicate methods to
IDebugContextService.
Thanks...
Samantha
Pawel Piech
<pawel.piech@wind
river.com> To
Sent by: Device Debugging developer
platform-debug-de discussions
v-bounces@eclipse <dsdp-dd-dev@xxxxxxxxxxx>
.org cc
platform-debug-dev@xxxxxxxxxxx
Subject
23/10/2007 07:14 [platform-debug-dev] Re:
PM [dsdp-dd-dev] Multicontext
debugging proposal
Please respond to
"Eclipse Platform
Debug component
developers list."
<platform-debug-d
ev@xxxxxxxxxxx>
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
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev