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

[Jared Burns <jaredburns@xxxxxxx>]

Right.

In our proposal, I mention that the debug view will keep a Map that associates 
launches with their submissions. This means that if you have two launches 
that enable the "jdt.debugging" context, the map will have:
 launch1 -> jdt.debugging submission 1
 launch2 -> jdt.debugging submission 2

When a launch terminates, its submission is deactivated. So the "context" will 
stay active in the workbench until the last launch with a submission for that 
context terminates.

To answer your earlier question about bringing views to the top... The view 
currently does this. The context-to-view binding tells the debug platform 
which views are "applicable" to a debug model. That is, which views are 
useful to the user for that model. If the Variables view is useful to your 
model, then you'll want to make sure it's associated with your context.

To make this easier on clients, I wrote our support to honor the context 
hierarchy such that the context-to-view bindings inherit any context-to-view 
bindings of the context's parent. The debug platform provides a "debugging" 
context that is bound to the generic debugging views - Debug, Variables, 
Console, Breakpoints, and Expressions (autoOpen=false). So for your 
context-to-view binding to include these views, you just need to define your 
context as extending the debugging context. The jdt.debugging context works 
this way. It just extends debugging and adds the Display and Threads and 
Monitors view.

An added note on inheritence (this will all make it into the ISV doc): Child 
context-to-view bindings can override the behavior of their parents. I 
mentioned that the "debugging" context is bound to the Expressions view, but 
it's defined with autoOpen="false". If you have a debugger that actually 
wants the Expressions view to auto-open, you can just extend the debugging 
context and override the contextViewBinding for your own context.

- Jared

On Friday 05 March 2004 06:53 pm, Jeff Turnham wrote:
> Hi,
>
> Upon further reflection (and a nice cold beer)....I see that when the
> DebugView requests to activate/deactivate contexts, the base Workbench
> Context support should protect against a Context getting disabled by the
> Debug View if another party requires the context to remain active.
>
> http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ui-home/contex
>ts/contexts.html "In addition to managing the set of enabled contexts in
> this manner, the API also considers that the enabled state of a context is
> a shared resource and is careful to protect clients against inadvertently
> disabling contexts enabled by another client. In order to facilitate this,
> each client much add its set of contexts it wishes to enable to the
> appropriate level (workbench, perspective, or part) and a union of all
> client's submissions at each level is calculated."
>
> The only sticking point is that I think the granularity of "client" in the
> description above would be referring to the DebugView.  So I would think
> you would still have to implement the logic necessary to know not to
> request deactivation of a Context until all the launches for which that
> Context is applicable have terminated.
>
> Thanks...
>
> ---------------------------------------------------------------------
> Jeff Turnham
> ---------------------------------------------------------------------
>
> Jeff Turnham/Toronto/IBM wrote on 03/05/2004 06:50:00 PM:
> > Hi Jared,
> >
> > Yes this does sound like a good solution.  As soon as its released
> > I'll check it out and parade it around here for review.
> > A few questions:
> >
> > EnabledSubmissions
> > -------------------
> >
> > I'm a little fuzzy on exactly what an EnabledSubmission consists of
> > and what "disabling" one would mean.   I'll tell you what I think it
> > means and you can tell me how far off I am ;-):
> >
> > When an IAdaptable is selected in the Debug view and an attempt is
> > made to activate the context, there are 2 possibilities:
> >
> > a. The context is currently not activated, so the Debug view
> > activates it.  In this case, the Debug View is assuming
> > responsibility for both activating the context and deactivating the
> > context when the launch that caused the activation terminates.
> >
> > b. The context is already enabled by either another launch, or by
> > the 3rd party mechanism you mention below (programmatically enabling
> > the context in the Workbench).  In this case, the Debug View will
> > not be activating the context and NOT assuming responsibility for
> > deactivating the context when this launch closes.
> >
> > So the EnabledSubmissions is the mechanism by which this information
> > is captured.  If I'm close, then I would have called it something
> > like LocallyEnabledContexts ;-)
> >
> > Bring To Top Support
> > --------------------
> >
> > Can you expand a bit on what it means to "bring to top" a view when
> > a context is activated?
> > Currently I don't set up a contextViewBinding between the C context
> > and the Variables view (since that view is always there).  However
> > we would likely always want the Variables view to be "at the top" by
> > default.  So I'm not sure what impact "bring to top" has on the
> > behaviour of the Views.
> >
> > Thanks...
> >
> > ---------------------------------------------------------------------
> > Jeff Turnham
> > ---------------------------------------------------------------------
> >
> > platform-debug-dev-admin@xxxxxxxxxxx wrote on 03/05/2004 05:36:59 PM:
> > > 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