[
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
|
Good ideas. I've released these changes to CVS and they should show up in the
M7 build. The only change is that I called it an IDebugModelProvider with a
method "String[] getModelIdentifiers()". That way it can return strings which
are looked up in the XML via our debugModelContextBinding extension point.
- Jared
On Tuesday 10 February 2004 10:42 am, Darin Wright wrote:
> 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
>
>
> _______________________________________________
> platform-debug-dev mailing list
> platform-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
