Re: [platform-debug-dev] Some questions about using the LaunchView Conte

[Jared Burns <jaredburns@xxxxxxx>]

DarinW and I talked a bit on the phone about how actions will fit into
the context support and then Luc and I sat down at a whiteboard and came
up with the following proposal:

The debug view will:
1. When an IAdaptable is selected in the Debug view, the view will
attempt to get an IDebugModelProvider adapter. If successful, it will
activate the appropriate contexts in the workbench. The view will keep a
Map to track which "EnabledSubmission"s were provided by each launch.
2. When a launch terminates, the Debug view will disable the
"EnabledSubmission"s (I didn't make up the name! :) associated with that
launch.

The debug view's context listener will:
1. When a context with a "contextViewBinding" is activated in the
workbench, promote (open/bring to top) views associated with that
context.
2. When a context with a contextViewBinding is deactivated in the
workbench, close views associated with that context.

The workbench already does:
1. When a context is activated, show actions that are bound to that
context.
2. When a context is deactivated, hide actions that are bound to that
context.

I think this gives us everything we want. It means that actions and
views will appear when you need them and will only disappear when you're
done.

It also means that third parties will be able to augment the debug
view's default behavior by activating and deactivating contexts at
different times. For example, if a third party wants their views and
actions to appear when a launch is created (instead of when an element
is selected), they could just activate the appropriate context in the
workbench and the debug view's listener will notice.

Good, bad, ugly?

- Jared

On Thu, 2004-03-04 at 13:29, Jeff Turnham wrote:
> Hi Jared,
> 
> >> 1.  It seems that on a fresh Debug Perspective, the
> LauchViewContext
> >> Listener deems there to be no active contexts so it shows all
> views.
> >I don't know how this is possible. If you can reproduce this, please
> file
> >a bug report against Platform-Debug.
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=53798
> 
> >Views whose content is selection-based and debug-model specific
> shouldn't 
> >specify autoClose="false". For example, Java's "Threads and Monitors"
> view 
> >can only show useful content when Java Debug elements are selected.
> If the 
> >user selects a C stack frame, this view no longer makes sense so it
> allows 
> >itself to be closed.
> >Can you explain why you would want your Compiled Language views open
> when 
> >someone switches to debugging PHP but you wouldn't want them open
> when the 
> >target terminates?
> 
> We have experimented with having more than 1 Debug Target running,
> each with different contexts.   The views disappearing/reappearing as
> you move around the Debug View is distracting and perhaps initially
> confusing to users (e.g "Does the fact that my Registers view
> disappeared mean my C Debug Launch has terminated?").  
> 
> I'm not sure if any persistence support has been added since M7 (I
> will be moving up shortly), but the closure of views has a drastic
> impact on the usability of the views.   For example if I am deep into
> some element's tree in some view, then goto some other context and
> then come back, I should be exactly where I left off.  I will be
> looking at this more closely, but will start a new thread for that
> when I have more info.
> 
> This is really a question of what the lifetime of a View should be.  
> Rather than basing it on the selected element's Contexts, we (Pete,
> Wayne, myself) are thinking it should be based on the lifetime of the
> Context in the Debug View.   Since opening/closing Views is such a
> heavyweight operation from a visual point of view, it should be done
> with care, when something significant happens.
> 
> Here's a thought:  Is there a visual cue that could be used to show
> that a view is not "in Context of the currently selected element"
> other than removing the view?   Perhaps some marking on the view
> title, like greyed or italicized text?  Moving views around in the tab
> order will likely be as distracting as removing the views all together
> so I don't think that's a solution.   I haven't thought it through
> yet, but I just wanted to throw it out for discussion.
> 
> Thanks...
> 
> --------------------------------------------------------------------
> Jeff Turnham
> ---------------------------------------------------------------------