[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-vcm-dev] Team Operations from top level menus
|
In light of these difficulties, I would go for a "Team" top level menu as
a place to hang off provider menus. I am really looking for an agreed
place rather than trying to push any specific option. This assumes that
providers are not mutually exclusive.
The CVS non-contextual operations are accessed by launcing the "CVS" view.
From there, you can create repository connections, browse the project
structure
and checkout modules. I suppose that we could adopt a similar approach
for other providers, although, it seems overkill for what may be a few menu
options
with no need for a browser as in the CVS case. Perhaps the CVS plugin
could use
the new Team menu to launch the repository browser rather than through the
View mechanism.
In WSAD 4.x, the installation allows you to not have any VCM, I presume for
WSAD 5 the same will hold. We would then have an empty Team menu.
Bryan Stephenson
----- Original Message -----
From: <Kevin_McGuire@xxxxxxx>
To: <platform-vcm-dev@xxxxxxxxxxx>
Sent: Thursday, May 02, 2002 4:22 PM
Subject: 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
>
>
>
>
> _______________________________________________
> platform-vcm-dev mailing list
> platform-vcm-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
