[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-vcm-dev] Team Operations from top level menus
|
>>Is there any way to have the Workbench adjust the menu structure
>>according to the number of active team providers?
As James indicated, this support doesn't exist and won't for 2.0,
unfortunately.
>>The number of active team providers is determined by checking project
>>Natures associated with the set of open projects.
There are cases where you may not have any projects at all, yet still want
to do repository operations. For example, if you maintain some kind of
active connection to a server and need to start that connection, Clearcase
may have 'view' specific operations, etc.
The reason we need the pulldown is primarily for the cases where there is
no project context. Also note, I think its true that actions in the
pulldowns are *not* filtered by nature ID (this relates to a point Bryan
suggested in his email to this group).
Kevin
Jim Wright - IBM
Research To: platform-vcm-dev@xxxxxxxxxxx
<jwright@xxxxxxxxxxxxxx cc:
> Subject: RE: [platform-vcm-dev] Team Operations from top
Sent by: level menus
platform-vcm-dev-admin@
eclipse.org
05/01/2002 04:32 PM
Please respond to
platform-vcm-dev
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="&Run Foo Tool"
menubarPath=org.xyz.xyzMenu/group1"
....
</action>
<action id="org.xyz.runBar"
label="&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
_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
