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

[Kim Horne <Kim_Horne@xxxxxxxxxx>]

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