[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] FYI (for early access clients of activities and roles)
|
It seems to me that active activities are better suited to being
tracked per perspective instead of workbench window. Perspectives are
already used to show a subset of actions in the UI and separate work
topics (CVS vs. debug, etc), so having activities work with
perspectives would be natural.
The proposal document on Platform UI web pages makes a distinction
between static and dynamic UI scalability, so maybe there's some
interplay I don't see between use of perspectives, contexts and
activities. Can someone explain this in more detail?
On Nov 7, 2003, at 10:43 AM, Chris McLaren wrote:
here is a recent discussion you might want to read bottom up..
thanks,
chris.
----- Forwarded by Chris McLaren/Ottawa/IBM on 11/07/03 10:38 AM -----
Chris McLaren/Ottawa/IBM
11/07/03 10:41 AM
To
Konrad Kolosowski/Toronto/IBM
cc
Douglas Pollock/Ottawa/IBM@IBMCA, Jared Burns/Minneapolis/IBM@IBMUS,
Kim Horne/Ottawa/IBM@IBMCA, Michael Van Meekeren/Ottawa/IBM@IBMCA,
Nick Edgar/Ottawa/IBM@IBMCA, Tod Creasey/Ottawa/IBM@IBMCA, Andre
Weinand/Zurich/IBM@IBMCH
Subject
Re: getActiveActivityIds()Link
It is my guess that help should play just like preferences do.
Some background info: enabled activities at the workbench level vs.
active activities at the workbench window level
IActivityManageris available fromIWorkbenchand it maintains the set of
enabled activities. An enabled activity is something the user could
do. (Remember, roles are just sets of enabled activities.) This is
maintained at the workbench level because no matter how many workbench
windows may be open, its still the same user using all of them.
In contrast, an active activity is something the user is currently
doing. We expect this could be different by workbench window. e.g. A
user, according to his role, might be able to both work with cvs and
debug java software, but they might only be working with cvs in one
workbench window and only debugging java software in the other.
We expect that active activities will almost always be a subset of
enabled activities. Forgive me if the word 'almost' here is a little
confusing: we have envisioned possible scenarios where a user
temporarily does an activity outside their usual set of enabled
activities [or role], without modifying their set of enabled
activities [or role] to do so. We have yet to see if this will play
out in practice.
What the preference dialog does now (or should be doing :)
That being said, the preferences dialog filters by the set of enabled
activities. This means the user can see all the preferences pages
related to activities that he could do, as opposed to those
activities he is currently doing. i.e. If working with cvs is within
your role, you should be able to view/modify preference pages related
to cvs whether or not your actually working with cvs and that time.
Technically, if you consider the 'almost' case above, preference pages
should filter based on the union of enabled activities plus the union
of all active activities on each workbench window, to catch the
occasional case of a workbench window having one of those temporarily
active activities not generally part of the users role
Furthermore, it is possible that the preference page dialog could
provide the option to further filter against only the union of all
active activities on each workbench window.
How help should might work similarly
I would expect that help's use of activities would be analogous to
that of the preferences dialog's use of activities, that help is
filtered by the set of enabled activities - things the user could do,
but is not necessarily doing right now. In this case, Konrad, all the
information you need is in
IWorkbench.getActivityManager().getEnabledActivityIds().
I further suppose you have both of the following options as well
(though I strongly recommend that the suggestion above be the primary
mechanism by which help is filtered according to activity). These
additional options are as follows:
1. to also include help related the union of all active activities
across all workbench windows. probably a smart idea to do this, but
really is just the icing on the cake. you can wait on this one if you
want.
2. to filter help only by the union of all active activities across
all workbench windows. this is an interesting one for help because it
could give a lot more context, something to think about.
Chris.
Konrad Kolosowski/Toronto/IBM
11/06/03 12:24 PM
To
Chris McLaren/Ottawa/IBM@IBMCA
cc
Douglas Pollock/Ottawa/IBM@IBMCA, Jared Burns/Minneapolis/IBM@IBMUS,
Kim Horne/Ottawa/IBM@IBMCA, Michael Van Meekeren/Ottawa/IBM@IBMCA,
Nick Edgar/Ottawa/IBM@IBMCA, Tod Creasey/Ottawa/IBM@IBMCA
Subject
Re: getActiveActivityIds()Link
I have replaced (code is in HEAD)
IActivityManager.getActiveActivityIds()
withPlatformUI.getWorkbench().getCommandManager().getActiveActivityIds(
). Keep me in the loop if other changes are needed.
At the moment there is only one Help window per workbench, not per
workbench window. How help might play in the activities framework
seems less and less obvious to me. The help usage of activities
should be treated as experimental, nevertheless I leave the activities
code in help enabled. We should keep in mind that we want to avoid a
need for completely independent solution for roles in help, that would
require user to do to much manual enabling/disabling.
Konrad Kolosowski
Eclipse Help System
Chris McLaren/Ottawa/IBM
11/06/2003 10:44 AM
To
Nick Edgar/Ottawa/IBM@IBMCA
cc
Konrad Kolosowski/Toronto/IBM@IBMCA, Tod Creasey/Ottawa/IBM@IBMCA, Kim
Horne/Ottawa/IBM@IBMCA, Jared Burns/Minneapolis/IBM@IBMUS, Douglas
Pollock/Ottawa/IBM@IBMCA, Michael Van Meekeren/Ottawa/IBM@IBMCA
Subject
Re: getActiveActivityIds()Link
A very temporary fix would be to
useIWorkbench.getCommandManager().getActiveActivityIds(), otherwise
here is the big explanation:
In meeting with Tod and Kim on Tuesday, we considered your recent use
case that different activities might happen in different workbench
windows, (e.g. someone might be debugging in one workbench window, but
not want to see the debugging commands in another), we realized that
the set of active activities maybe should be per workbench window, and
not a single set at the activity manager level.
Therefore,get/setActiveActivityIdswas removed fromIActivityManager,
and by the same token,isActive()was removed fromIActivity. It should
be noted thatget/setEnabledActivityIdsis still at the level
ofIActivityManager(as it makes sense that no matter how many workbench
windows there are open, its all the same user doing the work).
Yesterday I addedIActivationService getActivationService()to
bothIWorkbenchandIWorkbenchPage. This will be the new mechanism for
clients to activate and deactivate activities programatically. Clients
have their choice of which level they want their activity activated
for. I am considering the value of adding this method
toIWorkbenchWindowtoday as well.IWorkbenchPartSiteis fourth possible
choice, though I am reticent to do so right now. For clients that need
this, the workbench provides facilities to listen for part
activation/deactivation.
This system will replaceIContextActivationService, which will be
deleted shortly once the new interfaces work (by this afternoon, I
think). It works slightly differently thanIContextActivationServicein
that thegetActivationService()method brokers a new instance each time.
All undisposed instances ofIActivationServiceare used to calculate a
union, which represents the set of active activities at that
particular level. This helps maintain consistency in the set better,
which is effectively a shared resource.
Currently, I am calculating the set active activities for each
workbench window as follows:
For each workbench window, take the union of the set of active
activities at the workbench level and the set of active activities at
the workbench page level for the active workbench page in that
workbench window.
The question on my plate today is what to do with the command manager,
which exists only at theIWorkbenchlevel and has up until this point
expected a single set of active activities, not different sets of
active activities per workbench window.
ICommands brokered fromICommandManagerare expected to properly answer
the questionisActive()such that menus can determine command
visibility. As well, key bindings for commands depend on the set of
active activities, therefore key bindings could be different per
workbench window.
I am experimenting this morning with
havingICommandManager.setActiveActivityIds()take a map of tokens (for
instance, workbench window instances) to sets of active
activities.ICommand.isActive()as well as various methods in ICommand
andICommandManagerthat deal with keybindings would need to be
parameterized to accept this token.
I'll keep you posted today..
Chris.
Nick Edgar/Ottawa/IBM
11/06/03 10:01 AM
To
Chris McLaren/Ottawa/IBM@IBMCA
cc
Konrad Kolosowski/Toronto/IBM@IBMCA
Subject
getActiveActivityIds()
Chris,
I had to add getActiveActivityIds() back to IActivityManager since
Help was referring to it. It's implemented in terms of the
workbench's activation service.
Could you please advise Konrad on the best way to adapt Help to the
new API and cc me.
Thanks,
Nick
