RE: [platform-vcm-dev] Team Operations from top level menus

[James_Moody@xxxxxxx]

See my comments below.




|---------+---------------------------------->
|         |           Jim Wright - IBM       |
|         |           Research               |
|         |           <jwright@xxxxxxxxxxxxxx|
|         |           >                      |
|         |           Sent by:               |
|         |           platform-vcm-dev-admin@|
|         |           eclipse.org            |
|         |                                  |
|         |                                  |
|         |           05/01/02 04:32 PM      |
|         |           Please respond to      |
|         |           platform-vcm-dev       |
|         |                                  |
|---------+---------------------------------->
  >------------------------------------------------------------------------------------------------------------|
  |                                                                                                            |
  |        To:      platform-vcm-dev@xxxxxxxxxxx                                                               |
  |        cc:                                                                                                 |
  |        Subject: RE: [platform-vcm-dev] Team Operations from top level menus                                |
  >------------------------------------------------------------------------------------------------------------|



Hi,

I'm building the Eclipse portion of our Stellation SCM project.

I agree that none of the three choices Kevin outlined seem great.
Is there any way to have the Workbench adjust the menu structure
according to the number of active team providers?
I would like to avoid a provider-specific submenu when only one provider is
active, but have submenus automagically appear when two or more providers
are active.  (Another term for this is 'dynamic menu compression')

How about something like this?

- Team providers contribute their top-level actions to a 'virtual' menu,
   identified by an 'aliasToParentFor' attribute which specifies when
   the virtual menu should be aliased onto its parent.  Actions and
submenus
   having menubarPath values including the 'virtual' menu identifier will
have their
   menubarPaths adjusted automagically when such aliasing is in effect.

- The number of active team providers is determined by checking
projectNatures
    associated with the set of open projects.  (Of course, opening or
closing
    a project should trigger recalculation of this value).

- If there is only one active team provider, the corresponding 'aliased'
menu
   is not visible, and the top level provider-specific menu contributions
are directly
   appended to the Team menu, following the generic (non-provider-specific)

menu items.

- If there is more than one active team provider, the Workbench creates
submenus
   for each provider, appended to the Team menu:
         Generic Team menu items
         ...
         Team Provider 1 submenu
         Team Provider 2 submenu
         ...


JEM>> This is the ideal solution. However, I'm almost certain that this
JEM>> is not possible with the current workbench support for menu
JEM>> contributions. Someone is free to prove me wrong.

Here's a quick stab at some possible markup to clarify what I mean:

<extension point="org.eclipse.ui.actionSets">
     <actionSet id="org.xyz.teamActions"
         label="XYZ Workbench Actions"
         visible="true">
     <menu id="org.xyz.xyzMenu"
         label="XYZ Menu..."
         aliasToParentFor="1"
         path="Team/additions">
         <separator name="group1" />
     </menu>
     <action id="org.xyz.runFoo"
         label="&amp;Run Foo Tool"
         menubarPath=org.xyz.xyzMenu/group1"
         ....
     </action>
     <action id="org.xyz.runBar"
         label="&amp;Run Bar Tool"
         menubarPath=org.xyz.xyzMenu/group1"
         ....
     </action>
     ...
</extension>

If there is only one active Team provider, then "org.xyz.xyzMenu" becomes
an
alias for the top-level Team menu, and individual action menubarPath
attributes like "org.xyz.xyzMenu/group1" are swizzled to "Team/additions".
(More generally,  "org.xyz.xyzMenu/xxx" is swizzled to "Team/additions",
and
"org.xyz.xyzMenu/xxx/submenu1" is swizzled to Team/additions/submenu1"...)

When two or more Team providers are active, "org.xyz.xyzMenu" is visible
and
no menubarPath swizzling occurs.

It should not be necessary to load any Team Provider plugins in order to
generate the appropriate menu structure: the number of active team
providers
can be determined by checking project natures of open projects, and this
should allow proper manipulation of the extension metadata in the provider
plugin.xml files.

JEM>> It is absolutely necessary to load code here. A nature is just a
nature;
JEM>> I can't tell by looking at it that the cvs nature refers to a Team
JEM>> provider and that the Java nature does not. Iterating over the nature
JEM>> IDs cannot tell you whether the project is shared with a team
provider.

------------------------------

This is just one possible approach, and I don't know if this kind of plugin
metadata manipulation is practical.  If it is, this type of dynamic menu
compression could be useful for other plugin categories as well (code
generators, diagramming tools ... ).

Regards,
Jim