[platform-debug-dev] Re: [jdt-debug-dev] Context view management release

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

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