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

[Wayne Ho <who@xxxxxxxxxx>]

There have been some recent discussions
with the platform debug team, and IBM debug team about the debug scalability
issues and how activities and contexts may help resolve the issues.  The
recent discussions on activities and contexts in this mailing list are
timely, and it has become apparant that a discussion on a high-level design
proposal on how the debug team could use the concept of contexts to resolve
the scalability is needed, in part to help drive requirements for the activities
and contexts work.

First to quickly describe the debug
issues
1) At various times (i.e., depending
on the debug context or language being debugged) some debug views are more
relevant than others, and in some contexts, some debug views are not relevant
at all.
Within WSAD's debug perspective, a large
set of views are initially visible.  However, a number of the views
are not relevant when debugging certain languages such as JSPs, Java, SQL
Stored Procedures, etc.  For example, when debugging Java, the Registers,
Storage, Storage Mapping, Monitors, and Modules views are not relevant.
 However, those views are relevant when debugging compiled languages
such as C++.  

2) Depending on the debug context many
debug actions are not relevant/applicable.
Many debug actions (e.g., toolbar buttons,
menu actions in views and pop-ups, etc.) that are specific to a given debug
context (e.g., debugging Java) continue to be displayed (and enabled) when
they cannot be used in a different debug context (e.g., debugging C++ or
an SQL Stored Procedure)


Description of contexts for debugging:
The following is a description of how
debugging could take advantage of a concept of 'context'.  This is
intended to describe the user experience and help facilitate discussion
on how contexts/activities could be used.

1) Defining a base set of views
For a any given Eclipse-based product
that supports debugging, a base set of views and actions to be displayed
in the Debug Perspective can be defined.  
This base set of views and actions would
be displayed when there is no specific debugging context and all launches
are removed from the Debug view.  Ideally, this would be a minimal
set of views that are required to support the most common debug scenarios
for a given product.

2) Adding views using context
When a user chooses to debug an application,
a set of relevant views and actions for debugging the given language will
be added to the current Perspective.  If additional languages are
being debugged under the same launch, additional relevant views and actions
will be added to the Perspective.  In this way, views and actions
would accumulate as necessary.  In multi-language debugging scenarios,
any view(s) denoted as being more relevant, while stepping through a specific
language can be displayed in front/on top (e.g., in the case of a stacked
set of views).  The "more relevant" views can be initially
defined, but the user may choose to re-arrange views and these user changes
must be persisted.  In general, views that the user has chosen to
view, as well as their location, for each debug context must be persisted.

3) Removing views
When a given Debug Target is removed,
the views and actions associated with the Debug Target will be removed
from the current Perspective, unless those views are associated with another
Debug Target in the Debug view.  Views should only be removed from
an explicit user action (e.g., removing a Debug Target).  Views should
probably not be removed if they were explicitly added (manually) by the
user.


JNI Debugging Scenario
The following is a brief description
of how the above might work for a JNI debugging scenario.
If the user is interested in debugging
JNI (e.g., Java and C++), the user launches the application in debug mode.
 Assuming the user has set a breakpoint in the Java code, the Debug
Perspective opens.  The base set of views for the product are visible
(let us assume within WebSphere Studio the views visible are the Debug,
Servers, Variables, Breakpoints, Expressions views, the Outline view, and
at the bottom of the Perspective the Console and Tasks views).  The
debugger stops at the Java breakpoint.  No additional views are opened
as the base view already contains the relevant Java debugging views.

The user steps through the code and
eventually steps into the C++ code.  At this point the relevant compiled
language debug views are added to the Perspective (e.g., the Monitors,
Modules view, Storage, etc.).  Not all views associated with the C++
debug context necessarily need to be opened automatically.  There
may be some views that are only opened manually by the user (for example,
perhaps the Display view is such a view that would be opened manually via
a context menu).  Actions relevant to C++ would also appear.  Actions
irrelevant to C++ would be disabled when C++ debug target (or it's children)
are selected.

Once the application runs to completion,
the views remain in the Perspective (e.g., allowing the user to look at
the relevant console output after running).  Once the user removes
launch from the Debug view, all of the added views associated with the
C++ debugging are also removed from the Perspective.


Comments, questions?

Regards,
Wayne

Chris McLaren wrote on 11/20/2003 10:39:49 AM:

> 
> 1. Recent feedback from our usability lead suggested some changes
to
> the roles and activities framework. Primarily, that the concept of
> 'roles' be removed from the activity framework and in its place 
> activities should be grouped by category. This, in a way, is a 
> subtle change - 'roles' effectively were means of categorizing 
> activities. Calling this grouping mechanism 'category' removes some
> of the semantic weight that comes with the term 'role'. 
> 
> These changes mean that: 
> a) the org.eclipse.ui.roles extension point is removed. 
> b) IWorkbench.getRoleManager() and associated code is removed. 
> c) the org.eclipse.ui.activities extension point is extended to 
> allow definition of categories as well as the association between
> categories and activities. 
> d) IWorkbench.getActivityManager() is extended to provide java api
> to categories. 
> 
> 
> 2. We've recently come to the understanding that the activity work
> is really two distinct parts, as evidenced by two sets of use cases
> that don't overlap: 
> 
> a) Part one - Limit available functionality 
> 
> This part of the activities work allows the user to select a subset
> of available functionality. Any functionality not selected is simply
> not available in the product. 
> Some applications call these individual pieces of functionality 
> 'modules' or 'components', we call them 'activities'. 
> 
> This part is analogous to how an install application works. The 
> differences between this and an install application are: 
> i) it can be changed on the fly. (with an install application, a 
> user typically needs to exit the application, reconfigure, and restart)
> iii) there are various trigger points in the application which could
> cause it to change. (some applications have this ability as well -
> microsoft word, for instance, will automate its setup application
to
> install conversion filters if you try and open a file without the
> correct conversion filter installed) 
> 
> Activities can belong to one or more Category. Activities can 
> require one or more activities to be enabled before they can be 
> enabled. Activities are bound to functionality via 'pattern 
> bindings' a mechanism to associate an activity with identifiable 
> objects in the product. (think 'id' attribute in plugin.xml 
> elements) Any activity (or a category as a whole) can be enabled or
> disabled by the user (respecting, of course, the fact some 
> activities require other activities) 
> 
> It is this part that is of importance to the scalability concerns
of
> preference pages, help content, etc. These use cases care about 
> limiting available functionality. As well, it is this part that most
> complements the work happening in Equinox. 
> 
> b) Part two - Distinguish what the user is actually doing 
> 
> This part strives toward an adaptive user interface which changes
> depending on what the user is doing. With this part, an application
> could highlight the most needed functionality to the user on menus
> and toolbars, choose the correct set of key bindings for particular
> uses, show and hide views automatically, etc. The application 
> determines what the user is actually doing and various systems react
> appropriately. 
> 
> We call what a user is or is not doing a 'context'. Contexts can 
> require one or more contexts to be active before they can be active.
> Any context can be activated or deactivated by the application 
> (respecting, of course, the fact some contexts require other contexts)
> 
> It is this part that is of importance to the scalability concerns
of
> the debug team. This use case cares about showing the most 
> appropriate functionality and hiding functionality that it 'out of
> context'. That functionality could be views, or commands/actions,
etc. 
> 
> c) Differences between part one and part two 
> 
> Part one is defined by the user. The enabled state of activities is
> persistent - independant of what the user is actually doing. It 
> defines what the user could do. 
> Part two is defined by the application. The active state of contexts
> is transient - dependant on what the user is actually doing. It 
> defines what the user is actually doing. 
> 
> Currently, we are giving the term 'activities' to both the 
> 'activities' of part one and the 'contexts' of part two. It has been
> proving difficult to align these two precisely. 
> 
> For instance, there might be an activity called 'Java Development'
> which the user can explictly turn on or off (or is turned on or off
> on behalf of the user via a trigger point). There might be a context
> called 'Debugging' which is turned on or off by the application, 
> depending on whether or not you are currently debugging a target 
> application. 'Java Development' is not necessarily a context that
> the application turns on or off. 'Debugging' is not an activity that
> the user would choose to turn on or off. 
> 
> There is a relation between activities and contexts, sometimes one
> to one. That relation is simply the same relation that activities
> has to any other system - the ability to filter it based on pattern
> bindings. i.e. Certain contexts might not even be available to be
> activated or deactivated by the application if they are filtered out
> by activities. 
> 
> d) What I would like to do from here 
> 
> Following M5, I propose to add a distinct 'context manager' with a
> contexts extension point. Clients of part one would change very 
> little, most likely not at all. Clients of part two, like the debug
> team for instance, would require to rename a few things but would
> otherwise be unaffected. 
> 
> 
> Questions? 
> Chris.