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

[Chris McLaren <Chris_McLaren@xxxxxxxxxx>]

Wayne, thanks for this description. You and I are in sync with regards to 
how 'contexts' will faciliate this work. It might be worth it for me to 
describe where 'activities' and 'contexts' are as of today:

- Activities -

Activities have been taking priority, and the API is largely complete. 
What remains in activities is work to ensure that various UIs within the 
workbench adhere to the filtering that activities define, and that some 
UIs expose smart workflow mechanisms that allow the user to 'grow into' 
new activities in a more natural way that simply having them choose their 
activities explicitly in some UI. (i.e. Being able to create a new Java 
project in the new project wizard to enable the 'Java Development' 
activity as opposed to requiring the user to go to an activities dialog 
and select a check box which says 'Java Development')

Activities do effect debug, significantly: they can filter out debug 
views, debug commands, and even the debug perspective as a whole, but it 
is on a macroscale - debug is affected by 'activities' like any other set 
of plugins in the sense that 'java development' (or a similar 
coarse-grained activity) could be completely filtered out of the 
application by the user, hence you the user would never get as far as java 
debugging to be concerned with the use cases you describe below.

Assuming, however, that the user has enabled the required activities such 
that debug is not filtered out of existence entirely, then contexts can 
come into play.

- Contexts -

The contexts API is largely complete as well:
1. There are facilities to define contexts and their interdependancies 
(via the org.eclipse.ui.contexts) extension point. 
2. One can activate or deactivate contexts via API at various levels in 
the workbench (workbench, window, page, part).
3. One can receive notification when the set of active contexts change, or 
changes to particular contexts, via IContextManager.

What is missing? Primarily, I chose not to provide a mechanism in the 
contexts API to bind contexts to specific functionality. Activities, in 
contrast, has this mechanism built right into its API via its 'pattern 
bindings'. The reason this could be readily included in activities is that 
the semantics of binding an activity to some functionality is clearly 
defined - the binding always means 'functionality X is available when 
activity Y is enabled'. For contexts, however, I didn't think it was clear 
yet what the semantics of bindings would be for various systems.

For commands, the semantics are fairly clear: menus and toolbars should 
hide (or disable?) irrelevant commands. I am in the process of adding the 
ability to bind contexts to commands in the org.eclipse.ui.commands 
extension point, but it remains to be experimented with if the binding 
should specify whether the command should be hidden altogether or just 
disabled when the user is out of context for that command. (Commands are 
already filtered on activity. Filtering on context would be next in the 
chain of filtering for those commands that made it though the activity 
filter)

For views, the semantics aren't as clear:
a) The big question: the Show View dialog currently filters out views 
based on activity, but should the Show View dialog also further filter 
context bound views? i.e. Should the user be restricted to only be allowed 
to open views that are currently in context?
b) One might define that a particular view is to be opened and brought to 
the top when a particular context becomes active, but another view is only 
to open itself on the bottom of a stack such that the user notices only 
the tab appearing. 
c) There might be some user defined behavior here as well - preferences to 
open certain views based on certain contexts. 
d) Also there might be some user-defined behavior on how those views might 
hide themselves once one leaves a context. How do we distinguish those 
views that might contain residual information (logs, etc.) that you might 
not simply want to disappear just because the debug target terminated, vs. 
those that can disappear automatically (variables view, maybe?). 

I'd like to work with debug to have them show/hide views programatically 
for now in response to events from the context manager before considering 
declarative API in the area of view-context bindings. 
IWorkbenchPage.showView(..) has been made public for this purpose, with 
the option to activate the view or not, (but it currently lacks further 
options on how to show - brought to front/pushed to back - currently views 
are always brought to front). IWorkbenchPage.hideView(..) also exists. 


Chris.