[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Changes to action enablement
|
Support for the filter tag still exists. However if you use the visibility
tag the filter tags are ignored.
To forsee another question: "does the visibility tag replace the
objectClass attribute of the popup menu contribution?". Answer: No. You
still need to define a particular type for object contributions. After you
do that, you can qualify the contribution with additional attributes using
the filter / visibility element.
"Randy Giffen/OTT/OTI"
<Randy_Giffen@xxxxxxx> To: platform-ui-dev@xxxxxxxxxxx
Sent by: cc:
platform-ui-dev-admin@e Subject: Re: [platform-ui-dev] Changes to action
clipse.org enablement
11/30/01 03:03 PM
Please respond to
platform-ui-dev
Does the visibility tag replace the filter tag?
If not, what is the difference?
(Again I would like to have the extension point for contributing marker F1
and Resolutions be as similar as possible to the extension point for
contributing marker actions)
"David Springgay/OTT/OTI"
<David_Springgay@xxxxxxx> To:
Sent by: platform-ui-dev@xxxxxxxxxxx
platform-ui-dev-admin@xxxxxxxxxxx cc:
Subject:
[platform-ui-dev] Changes to action
11/29/01 07:52 PM enablement
Please respond to platform-ui-dev
Hi,
In version 1 of Eclipse the enablement and visibility of window, view,
editor and popup menu action extensions was defined using a limited set of
elements in xml. The existing tags cannot adequately describe the
conditions when an action should be enabled or visible. To resolve these
issues, the following approach has been prototyped:
- if a plug-in is loaded, we will instantiate every action in the plug-in.
- new features have been added to the XML to define action enablement and
visibility. These features can be used to test system properties, plugin
installation, and object state. In addition, they can be combined using
AND, OR, and NOT tags. These features extend the existing markup, and do
not replace it.
A number of people rallied for eager plugin loading. This is infeasable.
Within the workbench action enablement should be quick to calculate. If it
is too expensive to calculate the enablement, the action should be
optimistically enabled, and a dialog should appear if the action is invoked
and cannot perform the required operation. See the CVS actions as an
example. This heuristic for expensive actions can also be applied to
action extension enablement. If we load a plugin to enable an action, it
may induce a tremendous delay, especially when there may be hundreds of
plugins in Eclipse. To avoid this delay, we must define the action
enablement criteria using XML. If it is not possible to define the
enablement criteria accurately using xml, the action should be enabled
optimistically.
The latest drop contains the following changes:
- an IWorkbench.refreshPluginActions(String pluginId) method has been
added. Using this method, you can trigger the creation of action delegates
for a particular plugin. The delegates are created only if the plugin
itself has been activated.
- a new enablement element has been added to action markup. This can be
used to define the enablement criteria for any action, and is a sub element
of the action element.
- a new visibility element has been added to popup menu extension action
markup. This can be used to define the visibility criteria for the action,
and is a sub element of the object contribution element.
For more information on the visibility and enablement criteria, see the
attached html doc.
(See attached file: expressions.html)
If you have any comments on the enablement criteria, please respond.
Dave
