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

[Jeff Turnham <turnham@xxxxxxxxxx>]

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/contexts/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