Re: [platform-ui-dev] Activities and Contexts - Important Update

[Chris McLaren <Chris_McLaren@xxxxxxxxxx>]

> Originally, we were hoping that activities would
solve the entire 
> debug problem - i.e. displaying the correct set of views/actions 
> based on what was being debugged. However, the problem we discovered
> is that the debug platform provides a superset of actions and views
> that many debuggers share different subsets of. Thus using 
> activities to filter does not work well (since the views actions all
> come from the same plug-in). As well, a more dynamic solution is 
> desired - i.e. we'd like views/actions to appear and disappear as
> they are required rather than having a superset of views/actions 
> visible all the time. 
> 
> For  example, the debug platform provides the following views:
> breakpoints, variables, expressions, registers, and storage (note
- 
> in reality, the registers and storage views do not yet exist in the
> platform, but may be contributed during the 3.0 time frame). When
> debugging "Java", the registers and storage views are not
> applicable. When debugging a functional language, the expressions
> view is not applicable. I suppose one approach would be to define
> unique prefixes for each view and associated actions such that we
> may be able to define activities properly to identify the subset of
> views/actions used by each debugger. 
> 
> Then, we still have the issue of automatically changing the set 
> enabled activies as the user debugs. Thus, when the user starts a
> debug session, the appropriate views should come into being. When
> the sessions is terminated (and removed), the views can then be 
> hidden. I believe hiding the view when the debug session is removed
> is safe. This way, view content can still be viewed after 
> termination.  Once the user explicitly removes the debug session,
it
> should be safe to remove the output from that session (this is how
> console output is currently handled). Perhaps we can use contexts
to
> dynamically enable activities, based on what exists in the debug view.


Yes, activities are *not* the solution to these debug
use cases, but I 
believe contexts *are*. 

Activities filter everything first. They are only
enabled/disabled by 
the user, either explicitly in an activities UI, or,
slightly more 
transparently, along natural lines. (e.g. 'New Java
Project' to enable 
'Java Development', for instance.) 

Contexts come after the user's UI filtering and are
activated and 
deactivated by the application to reflect what the
user is actually 
doing.

For Wayne's use cases, you guys should be thinking
'contexts: 
activating/deactivating', and not really be thinking
about activities 
very much. 

Effectively, you could do all of Wayne's use cases
by hand using 
IWorkbenchPage show/hideView(), and ActionContributionItem.isVisible(),

and maintaining your own state, but the contexts API
offers a 
mechanism to formalize the process where one part
of your debugging 
code activates and deactivates these contexts, and
another separate 
part reacts to these changes. 

You can have a base 'debugging' context, and also
define more 
specific contexts for particular languages 'debugging
java', etc. 
multiple contexts can be active at once. it is the
responsbility of 
the debugger code to activate/deactivate these contexts
at the correct 
times.

The advantage of formalizing the system, besides less
overall code 
for you guys in the end, is that we can start to build
automated 
functionality on the context manager, not just commands
and views
bound to contexts, but user-defined opening of views,
change of 
keybindings, etc, all based on context changes.

Ideally, We'd like you to:
1. define a set of contexts.
2. have your debugger code activate and deactivate
as appropriate.
3. declare to which contexts commands and views should
be bound and 
have them react automatically.

Now number 1 and 2 works fine now, but number 3 we
have to do a bit 
by hand. I mentioned that I was in the process of
adding command-context 
bindings to faciliate number 3, (hence you won't need
to muck around with 
ActionContributionItem.isVisible) but suggested that
for views, debug 
itself listen for changes on the context manager to
show/hide views 
programmatically until we fully understand the semantics,
and then we 
might put that functionality into something like 'view-context
bindings'
in the XML API to automate the process.


Chris.