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

[Nick Edgar <Nick_Edgar@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.

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?

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.

The pros and cons of the different approaches, backed up by concrete use 
cases, should be captured in a design document, that can be posted off our 
proposals page for other interested parties to review when appropriate.

Nick




Kim Horne/Ottawa/IBM@IBMCA 
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
11/20/2003 12:07 PM
Please respond to
platform-ui-dev


To
platform-ui-dev@xxxxxxxxxxx
cc

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







I can handle the easy one! :) 

The "Activity Configuration" action has been moved to the Window menu, and 
it only shows up if you have at least one activity category defined in 
some plugin. 



Jared Burns <jaredburns@xxxxxxx> 
Sent by: platform-ui-dev-admin@xxxxxxxxxxx 
20/11/2003 11:51 AM 

Please respond to
platform-ui-dev


To
platform-ui-dev@xxxxxxxxxxx 
cc

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








Sounds good.

My first question's an easy one - How do you configure activities manually 
in 
current builds? The menu item seems to have gone away and I can't find 
where 
it was moved to.

Next, you hinted at something that's important to us - opening and closing 

views via activities/contexts. The last time I checked, toggling 
activities 
didn't effect view visibility. Will this change?

Multi-language debugging is a case that particularly begs this support. 
There 
are debuggers built on top of Eclipse that let the user debug the same 
program through many languages (imagine a JSP stack frame below a Java 
frame 
below a C frame). This is currently a bit of a mess for the user because 
they 
get a ton of views open in the debug perspective and they have to manually 

activate the applicable views everytime they move between layers. It would 
be 
great if applicable views would automatically either come to the top or 
open/close as the user selected stack frames.

On a side note, I noticed that the ability to exclude patterns from 
activity 
bindings recently went away. This seems like a problem with the way the 
pattern matching works today. For example, in Javaland, there's a 
"Developing 
Java" activity that matches to, say, org.eclipse.jdt.ui.*. Now we'd like 
to 
add an activity, "Developing Java Applets" with a pattern 
org.eclipse.jdt.ui.applets.*. My understanding is that as long as a 
pattern 
matches an enabled activity, it will appear. So you can't turn Applets off 

while Java is on. Assuming my understanding is correct, I'd like to see 
the 
pattern matching work differently. I think the algorithm should be to look 

for the pattern that most closely matches the ID in question and then 
filter 
based on the state of that activity. This would allow for people to 
provide 
effective activities at multiple levels of granularity within a namespace.

- Jared

On Thursday 20 November 2003 07:39 am, Chris McLaren wrote:
> 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.

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