[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-vcm-dev] Team Operations from top level menus
|
See me comments below.
|---------+---------------------------------->
| | Jim Wright - IBM |
| | Research |
| | <jwright@xxxxxxxxxxxxxx|
| | > |
| | Sent by: |
| | platform-vcm-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 05/02/02 05:27 PM |
| | Please respond to |
| | platform-vcm-dev |
| | |
|---------+---------------------------------->
>----------------------------------------------------------------------------------------------------------|
| |
| To: platform-vcm-dev@xxxxxxxxxxx |
| cc: |
| Subject: RE: [platform-vcm-dev] Team Operations from top level menus |
>----------------------------------------------------------------------------------------------------------|
James,
Thanks for the information - I'm learning more about Eclipse hourly, it
seems.
I've interleaved some comments and have another suggestion to offer.
At 04:46 PM 5/1/2002 -0400, James_Moody@xxxxxxx wrote:
>See my comments below.
>JW>>Is there any way to have the Workbench adjust the menu structure
>according to the number of active team providers?
>JW>>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')
><snip>
>.....
>
>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.
OK. I thought this might not be possible with the current workbench menu
support mechanisms (at least those based on plugin.xml markup). I suspect
it could be done programmatically, but introducing code to manage UI
presentation for multiple independent team providers seems a bit
problematic.
I've a different approach that does work with current Eclipse code; see
below.
>JW>> Here's a quick stab at some possible markup to clarify what I mean:
><snip>
>...
>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.
That's unfortunate, but not too surprising. I was thinking that, since
the
"Share Project" wizard can determine when a project has a "Team Nature",
there might be some persistent metadata (perhaps maintained by
org.eclipse.team.core) that could be used without having to load all of the
installed third party team provider plugins. Clearly this isn't so.
JEM>> It is actually possible. :-) (Shows what I know...) Apparently there
is
JEM>> a 'one-of' set that all providers are supposed to belong to. This is
an
JEM>> extra key that identifies the nature IDs as team providers. It exists
JEM>> so that only one provider can be added to a project at a time. We may
JEM>> be able to use this.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Here's a different approach.
It's a bit kludgy, since it doesn't automatically do the right thing, but
it
would let developers (end-users) customize their workbench as they prefer.
The basic idea is to specify two different top-level actionSets in the
plugin.xml markup. One actionSet defines the Team menu layout for use
when
only one team provider is in use; the other actionSet defines the preferred
menu layout for the case where two or more team providers are in use.
By default, only the single-provider action set will be visible in
newly-opened perspectives. However, the user can easily change this (via
Perspective | Customize | Action Sets). If the user enables both action
sets, it will look a bit weird, of course.
No code need be duplicated, since the two sets of contributions can use the
same set of classes. If a particular Action class needs to know if it's
invoked from the top menu (e.g. 'Team'), or from a submenu (e.g. Team/SVC),
this can be determined using IAction.getId().
I've written and tested some actionSet markup and a sample Action class
that pops up a dialog box with a title indicating how the action was
invoked.
To simplify the example, I'm adding contributions to the existing Workbench
menu rather than adding a dummy top-level Team menu.
Here's the sample markup and Java source:
<extension
point="org.eclipse.ui.actionSets">
<actionSet
label="Stellation Workbench Actions (Single Team Provider)"
visible="true"
id="svc.ui.topLevelMenuItems">
<action
label=" SVC Sample Action"
class="svc.ui.actions.SampleMenuAction"
menubarPath="workbench/additions"
id="svc.ui.topMenuItem">
</action>
</actionSet>
<actionSet
label="Stellation Workbench Actions (Multiple Team Provider)"
visible="false"
id="svc.ui.subMenuItems">
<menu
label="SVC Actions"
path="workbench/additions"
id="svc.submenu">
<separator
name="svcBegin">
</separator>
</menu>
<action
label="SVC Sample Action"
class="svc.ui.actions.SampleMenuAction"
menubarPath="workbench/svc.submenu/svcBegin"
id="svc.ui.subMenuItem1">
</action>
</actionSet>
////////////////////////////////////////////////
// SampleMenuAction.java
package svc.ui.actions;
import org.eclipse.jface.action.IAction;
import org.eclipse.jface.dialogs.MessageDialog;
import org.eclipse.jface.viewers.ISelection;
import org.eclipse.ui.IWorkbenchWindow;
import org.eclipse.ui.IWorkbenchWindowActionDelegate;
public class SampleMenuAction implements IWorkbenchWindowActionDelegate {
public SampleMenuAction() {}
public void run(IAction action) {
String dialogTitle =
(action.getId().equals("svc.ui.topMenuItem")
? "Main Menu SVC Sample Action"
: "Sub menu SVC Sample Action" );
MessageDialog.openInformation(_window.getShell(),
dialogTitle, "Action id: " + action.getId());
}
public void selectionChanged(IAction action, ISelection selection)
{}
public void dispose() {}
public void init(IWorkbenchWindow window) {
_window = window;
}
protected IWorkbenchWindow _window = null;
}
////////////////////////////////////////////////
As I said, it's a bit kludgy, but it might be a good way to help end users
manage clutter (and possible menu item name conflicts) until something
better comes along. And, it has the merit of working out of the box.
Comments?
JEM>> Very interesting. So if I understand correctly, the problems are that
JEM>> (a) the user is responsible for managing the action sets in the case
of
JEM>> multiple providers, and (b) each action has to be declared twice in
XML.
JEM>> It's certainly worthy of investigation. I'll have a chat with the UI
team
JEM>> to see what they recommend; they may know of some hacks we can use.