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

[Darin Wright <Darin_Wright@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.

Darin

Chris McLaren/Ottawa/IBM@IBMCA Sent by: platform-ui-dev-admin@xxxxxxxxxxx 12/03/2003 09:54 PM Please respond to platform-ui-dev

To:        Darin Wright/Ottawa/IBM@IBMCA, jaredburns@xxxxxxx, Wayne Ho/Toronto/IBM@IBMCA         cc:        platform-ui-dev@xxxxxxxxxxx         Subject:        Re: [platform-ui-dev] Activities and Contexts - Important Update

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.

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev