[
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
|
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
