Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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
        ...

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.

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

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

At 02:11 PM 5/1/2002 -0400, Kevin_McGuire@xxxxxxx wrote:
<snip>


The choices at present are:

1. One team menu, everyone just contributes their actions to it. If we have
more than one provider then these items will get mixed in with each other.

2. Every provider has their own top level menu (we are not a fan of this,
as explained).

3. There is a submenu in the Team pulldown for each provider.  This isn't
very nice for the single provider case.

Not really happy with any of these choices.

Kevin


_________________________________________________
Jim Wright
Stellation Project (Advanced Programming Tools Group)
IBM T.J. Watson Research Center

Back to the top