[
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)
|
Chris,
If help is not to provide its own way of enabling roles - we want this so
far, then showing help for active activities is important and should not
change. Help filters books using: workbench enabled activities + workbench
active activities + not defined activities. So when APIs are redesigned
that active activities will be per workbench window, an API that gives the
union of active activities for the whole workbench will still be needed by
help.
Konrad Kolosowski
Eclipse Help System
Chris
McLaren/Ottawa/IB
M@IBMCA To
Sent by: platform-ui-dev@xxxxxxxxxxx
platform-ui-dev-a cc
dmin@xxxxxxxxxxx
Subject
[platform-ui-dev] FYI (for early
11/07/2003 10:43 access clients of activities and
AM roles)
Please respond to
platform-ui-dev
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/I
BM To
Konrad Kolosowski/Toronto/IBM
cc
11/07/03 Douglas Pollock/Ottawa/IBM@IBMCA, Jared
10:41 AM 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
IActivityManager is available from IWorkbench and 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/I
BM To
Chris McLaren/Ottawa/IBM@IBMCA
cc
11/06/03 Douglas Pollock/Ottawa/IBM@IBMCA, Jared
12:24 PM 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()
with PlatformUI.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/I
BM To
Nick Edgar/Ottawa/IBM@IBMCA
cc
11/06/20 Konrad Kolosowski/Toronto/IBM@IBMCA, Tod
03 10:44 Creasey/Ottawa/IBM@IBMCA, Kim
AM 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 use
IWorkbench.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/setActiveActivityIds was removed from IActivityManager, and
by the same token, isActive() was removed from IActivity. It should be
noted that get/setEnabledActivityIds is still at the level of
IActivityManager (as it makes sense that no matter how many workbench
windows there are open, its all the same user doing the work).
Yesterday I added IActivationService getActivationService() to both
IWorkbench and IWorkbenchPage. 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 to IWorkbenchWindow today as
well. IWorkbenchPartSite is 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 replace IContextActivationService, which will be deleted
shortly once the new interfaces work (by this afternoon, I think). It works
slightly differently than IContextActivationService in that the
getActivationService() method brokers a new instance each time. All
undisposed instances of IActivationService are 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 the IWorkbench level and has up until this point
expected a single set of active activities, not different sets of active
activities per workbench window.
ICommands brokered from ICommandManager are expected to properly answer the
question isActive() 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 having
ICommandManager.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 and
ICommandManager that 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
