[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-debug-dev] Re: [jdt-debug-dev] Context view management released to HEAD
|
Furthermore, an IDebugContext should be able to specify a set of debug
contexts that are active. For example, if a debug model is a proxy/wrapper
to multiple underlying debug models (when doing cross language debugging
with a mixed call stack), the set of views visible should be the superset
of views defined by those debug models.
Thus, I propose the launch view obtains the IDebugContext adapter from the
selection in the debug view, which has a method to return a collection of
debug contexts to be active.
Darin
Darin Wright/Ottawa/IBM@IBMCA
Sent by: platform-debug-dev-admin@xxxxxxxxxxx
02/09/2004 02:14 PM
Please respond to platform-debug-dev
To: platform-debug-dev@xxxxxxxxxxx
cc:
Subject: Re: [platform-debug-dev] Re: [jdt-debug-dev]
Context view management released to HEAD
This suggests that we should use a level of indirection to retrieve the
active debug context. For example, the launch view could ask for an
IDebugContext adapter from the selected stack frame. If unavailable, the
debug model ID would be used. When available, the wrappering model could
provide an alternate "context id" via this interface (IDebugContext). The
interface would have a single method to return the associated debug model
context id.
Darin
Erin Harris/Toronto/IBM@IBMCA
Sent by: platform-debug-dev-admin@xxxxxxxxxxx
02/03/2004 09:28 AM
Please respond to platform-debug-dev
To: platform-debug-dev@xxxxxxxxxxx
cc:
Subject: Re: [platform-debug-dev] Re: [jdt-debug-dev]
Context view management released to HEAD
This could be a problem for debug adapters that wrapper other adapters.
Since the stack frame is wrappered, the model identifier of the wrapper
debug model is always given. If the model identifier of the sub stack
frame is given then model presentations would have to use getAdapter
religiously since they will now be passed a wrappered stack frame (e.g.
JDIModelPresentation.getText(Object) will be passed a wrappered stack
frame
instead of a JDIStackFrame). Currently the wrapper debug model handles it
by calling the sub debug model and passing in the sub stack frame.
Erin
Jared Burns
<jaredburns@acm.o
rg> To
Sent by: platform-debug-dev@xxxxxxxxxxx
platform-debug-de cc
v-admin@eclipse.o
rg Subject
Re: [platform-debug-dev] Re:
[jdt-debug-dev] Context view
01/30/2004 02:03 management released to HEAD
PM
Please respond to
platform-debug-de
v
The support is stack-frame-based to support multi-language debuggers. If
you have JSP, Java, XSL, and XML all in the same stack, you want the
perspective to update for the different languages as stack frames are
selected. But there's no way to accurately predict which views should be
shown for the thread containing those frames. So the best (least
disruptive) bet is to not add or remove views when the user selects a
thread (or other debug element).
This raises an important issue, though. In order for the current support
to function, debugger providers will have to make sure that their stack
frames return different debug model identifiers if they want to show
different views for them.
Debugger providers (we know you're out there!), is this currently how
your stack frames work? If not, would you be willing to change your
implementations to make use of this support?
Thanks,
- Jared
On Fri, 2004-01-30 at 07:10, Darin Wright wrote:
> The new support looks good. Being able to open views "underneath"
existing
> views is a great improvement. As well, the extension points/bindings
feel
> like the correct level of definition required from debuggers.
>
> Here are couple issues I found:
> * I noticed that the "context change" is based on a stack frame
selection.
> I am wondering if there is a specific reason that you chose a stack
frame,
> rather than a "debug element" of any kind. Should we be more generic?
> * Keeping track of views the user opens/closes manually is required (and
> we should persist this information). However, there appears to be a
> problem when I select the "Reset Perspective" action. This resets the
> debug perspective to its original state. This can cause views to close,
> which we (incorrectly) interpret as the user closing views. For example,
> after debugging some Java code, I reset the perspective, which closes
the
> Display view and the Threads & Montiors view. When I debug Java again,
the
> views do not re-appear, as I would expect. Since the action I invoked
was
> to "reset" the perspective, I would expect all cached information about
> the views to be "reset". We may need some more workbench support here -
> i.e. to be notified when a perspective reset is issued.
>
> Moving forward, how will action filtering be supported? Can we tie
> directly into the command/context filtering supplied by the workbench to
> filter debug model specific actions (i.e. by having debug model
providers
> associate contributed actions with a context)?
>
> Darin
>
>
>
>
>
> Jared Burns <jaredburns@xxxxxxx>
> Sent by: jdt-debug-dev-admin@xxxxxxxxxxx
> 01/29/2004 07:49 PM
> Please respond to jdt-debug-dev
>
> To: platform-debug-dev@xxxxxxxxxxx,
jdt-debug-dev@xxxxxxxxxxx
> cc:
> Subject: [jdt-debug-dev] Context view management released
> to HEAD
>
>
> I've released the first cut of context-based view management for the
> Debug perspective to HEAD. The changes to org.eclipse.debug.ui require
> the org.eclipse.ui.workbench from HEAD (which requires the latest
> org.eclipse.jface).
>
> The Debug UI provides two new extension points. One for mapping debug
> model identifiers to context identifiers. And one for mapping views to a
> context.
>
> When a stack frame is selected in the Debug view, we look for a context
> that matches its model identifier. If one is found (and it doesn't match
> the current context), it then automatically opens views associated with
> that context, closes views associated with other contexts (but leave
> unassociated views alone), and activates views within the context as
> appropriate. New views are opened "underneath" existing views using a
> new API from Platform UI and we examine the view stack (also using new
> API) so as to not activate a view if another applicable view is already
> visible on top of it. This means that we minimize flickering and UI
> instability.
>
> Also, we notice when the user manually opens or closes a view, after
> which we will no longer automatically open or close it (this isn't
> currently persisted, but probably should be).
>
> There's a new button on the Debug view which lets you toggle this
> "linking" behavior on and off.
>
> Developers just using Java will find that the first time they launch,
> the Display and "Threads and Monitors" views will open stacked
> underneath other views. Other than that, there shouldn't be any
> differences.
>
> Debugger providers will want to make two changes. First, views that are
> currently added to the Debug perspective using the perspective extension
> shortcut should have visible="false" added to their extension so as to
> not clutter the Debug perspective before they're needed. Second,
> contributors should use the two new extension points to specify which
> views are associated with their debug model. By default, views
> associated with contexts in this way will be automatically opened and
> closed. But the extension point supports specifying whether a particular
> view should be automatically opened or closed.
>
> I haven't written up the schema yet, but interested parties can look at
> the extension provided by org.eclipse.jdt.debug.ui.
>
> - Jared
>
> _______________________________________________
> jdt-debug-dev mailing list
> jdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev
>
>
> _______________________________________________
> platform-debug-dev mailing list
> platform-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
