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

[Chris McLaren <Chris_McLaren@xxxxxxxxxx>]

>Where are activity categories defined?  I don't see any mention of them in

>the activities extension point schema.
>Plus, the roles extension point schema is still there, even though the
>extension point itself has gone away.

This was part of our build submission this afternoon. The conversion from
roles to categories was a recent request.


>Chris, before going back to contexts, I would like to see concrete
>examples of where the current approach breaks down.  Materially, how does
>having activities and contexts differ from having activities with both
>enabled and active flags, plus the ability for activities to filter other
>activities?

If you read Julian's initial document into possible categories/activities
for WSAD (something I don't think I am entitled to post, unfortunately) or
look at similar filtering features in other products (think 'modules' in
NetBeans), you see sample sets of 'activities' that can clearly be enabled
or disabled by the user. (Perhaps the use of the term 'activity', rather
than 'module' or 'component' in this sense is confusing.)

Having a set of activities that a user can see for the purposes of enabling
or disabling is a basic design requirement for 3.0, one that has already
proven itself during the initial 'roles-spike through demo' and further
downstream demonstrations since. The use case (too many preference pages,
views, etc. showing in WSAD*) is clear - preference pages, help content,
views, etc. will all be filtered by this system. We are effectively past
this stage.

Now, given an instance of Eclipse with the user's suggested activities
enabled, we would like to have a better idea of what the user is actually
doing such that the application can be more adaptive to the user's needs.

We have at least two concrete use cases that fall under this category:

1. Scalability issues with Debug, considerably detailed in a document by
Wayne Ho, and in parallel discussed with Jared Burns (usually via this
mailing list). These questions surface: Can we cause views to become
visible or hide themselves based on whether or not we are debugging? Or on
what type debugging we are doing? (i.e. what's the source language
corresponding to the instruction pointer?) What about commands? Can they be
made visible or invisible along these lines?

2. Keybindings which change based on what the user is doing. This was
already working via keybindings 'scopes', but fall under this general idea.
Keybinding scopes, therefore, gave a specific use case. i.e. Keybindings
should be able to change based on whether the user is editing text, editing
java source, editing html, etc..

Therefore, we have these use two use cases defining new activities such as
'debugging', 'editing java source', etc.

The question now is, are these new activities - ones that the application
will manage 'activating' and 'deactivating' - ones that would appear in the
list that the user would globally enable or disable?

Consider the user choosing activities to enable or disable. I would suggest
that the user might enable or disable an activity like 'Java Development',
but not further enable or disable such fine grained 'activities' such as
'Debugging', 'Editing Text', etc. Also, I wouldn't give the user the option
that they could enable 'Debugging' but not 'Debugging Java Source' or visa
versa.

Having activities 'require' other activities helps in this regard, but many
of these fine grained activities you wouldn't want to present to the user
anyway considering that user wouldn't have fine grained control for
enabling or disabling them. 'Requiring' is best used between two visible
activities: say 'PDE Development' requires 'Java Development'

Therefore, using the same concept of 'activities' for all use cases
mentioned thus far at least requires that activities provide some notion of
'can user enable?: yes/no', such that many of these more granular
'activities' the user is not privy to turn on or off, or even see.

This is possible, but lets now look at things in another direction. The
keybindings use case wants to give the user the option to edit keybindings
against specific 'activities' that the application will activate and
deactivate. Not many, at least not all, activities in the sense of
'modules' or 'components' will be managed in this way. Requiring this
would, I beleive, will limit the ability to partition functionality along
lines of 'modules' or 'components'.

For instance, it would not be a good idea to allow key bindings to be
defined against the WSAD* 'Web Development' activity, unless it was known
that there would be specific code in the application to identify when the
user is actually beginning 'web development' and could activate that
activity appropriately. We should allow product developers to partition
functionality along lines like 'web development' as 'modules' or
'components' without requiring them to make in-code discrimination of when
the use is *actually doing* web development.

Conceptually then, we would require that activities provide some notion of
'is activation well managed? yes/no'. One solution specific to this
keybindings problem would be to introduce a mapping to identify those
activities that should be available for keybindings, but the ultimate
result of such a mapping is just a list of all activities that implicitly
answer yes to the question 'is activation well managed?'

It is my assertion that activities that would answer 'yes' to 'can user
enable?' typically answer no to 'is activation well managed?', and visa
versa. That use cases for 'modules' for the user are different than use
cases for managing context. That the nature of the activities themselves in
each case is different.

You may or may not agree (yet), and all is not lost - both these attributes
('can user enable?' and 'is activation well managed?') could be added to
activities and we could still use one object - and a smaller API.

Then there is the interesting question of 'could activities filter out
themselves?' I had envisioned that activities would exist at a level above
the functionality that could be filtered out. What would it mean that an
activity is filtered out by another activity? Certainly it can't mean the
activities UI doesn't show filtered out activities, as you would have a UI
that slowly collapsed its items until nothing was left. In effect, the 'big
crunch' of functionality filtering. Obviously, the activities need to exist
to be able to be reenabled. So at best I guess what it would mean is that a
filtered-out activity could not be activated or deactivated.

This self-filtering confuses me, but lets push forward with this idea of
keeping them the same.

Pattern bindings. These currently determine what functionality is
completely filtered from the application. Preference pages, help content,
views, etc. all go away if they don't match an enabled activities pattern
binding. Lets look at the last one I mentioned - views. If a view is bound
to a disabled activity, it shouldn't appear anywhere. (The only exception
to this is if the Show View dialog or something similar is a trigger point
to enabling functionality, and I'm not convinced it should be yet).

Well this helps the primary scalability use case somewhat, namely the
monstrous proliferation of views in WSAD*, this form of filtering views
doesn't help the debug case. They further want to tie views to
showing/hiding based on whether an activity is 'activated' (by them,
programmatically), and not simply enabled.

So we would need to distinguish patterns bound to 'enabled' activities vs.
patterns bound to 'active' activities.

In summation, it was my 'proposal' at the end of my last email to separate
the two and save a whole bunch of state and confusion of terms at the
expense of
a) possibly realizing sometime in the future that I was wrong and these
really are the same things after all.
b) some extra api.

If we can agree that 'activities' are different from 'contexts' based on
the above arguments (again, i would prefer the terms 'modules' and
'activities' respectively), we would end up with:

activities: can be enabled or disabled by the user. bindings between
activities and patterns which match functionality link what functionality
is available to what activities are enabled. activities can require other
activities (i.e. one should not be allowed to disable 'java development'
while enabling 'pde development')

contexts: can be activated or deactivated by the application. contexts are
subject to being filtered by activities. functionality can be bound to
contexts to mean 'functionality should be highlighted/made visible/brought
to the forefront' whenever the context is activated, and visa versa.


>I am concerned about the size of this API.  The activities support
>currently consists of 5 packages and 60 classes (2/5 of which are API)
>plus one extension point with a few elements.  I would like to avoid
>duplicating this if we can accomplish the same thing by keeping 2 bits on
>activities rather than one.
>
>I would also like to understand whether there are opportunities for
>reducing the size of the current API and implementation.  We need to
>understand and enumerate the use cases for parts 1 and 2, including at a
>minimum the support for what used to be known as roles, the command
>manager scenarios and the dynamic debug scenarios.  The API should be
>complete enough to handle these cases, but no more complex than necessary.

Concern noted.

The activities API was designed a little bit different than other API's in
the workbench. First, it is a true client to the Equinox work. It provides
a handle-based API which manages change based on changes to the
ExtensionRegistry. Second, it was designed to be completely decoupled from
workbench. Workbench has no dependancies on the activities internal
packages, and activities has no dependancies on workbench at all. Finally,
some code in there that is transitional - some duplication remains. These
three things add some weight to the API.

I suggest that we discuss the immediate issue in this email within this
forum (platform-ui-dev), and we can review the API within the platform-ui
team. Perhaps we will choose to proxy this API somewhat. Personally, I
don't really think that the number of internal packages should a subject of
discussion in this forum at all.


Thanks,
Chris