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

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

It sounds like contexts play much the
same role that perspectives have played in the past.  Perspectives
have always had this funny split role of defining part layout as well as
filtering commands, and the contents of the "show view", "new"
and other such menus.  It sounds like this second role of perspectives
is now being done by contexts.  As a user I think this is a positive
step - I often switch perspectives in order to obtain a different part
layout while working on the same task, thus I find it annoying that this
disables the various commands and menus that I use frequently. I find myself
switching to the Java perspective just to hit Ctrl+Shift+T to open a type,
and then switch back to the perspective I was in before. Of course I can
manually customize all of my perspectives to have the same commands and
menus, but this is tedious configuration work.  So, I welcome the
idea of separating "context" or role change from layout change.

To avoid competing configuration stories
in 3.0, you may want to consider deprecating the portions of perspective
functionality that is now being done by contexts, or somehow link the two
together (for example a perspective could define a default set of contexts
for that perspective, and perspective extensions could add more contexts
as appropriate).

John


platform-ui-dev-admin@xxxxxxxxxxx wrote on 12/03/2003
10:54:39 PM:

> 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.