Re: [platform-ui-dev] Changes to action enablement

["Randy Giffen/OTT/OTI" <Randy_Giffen@xxxxxxx>]

I think it is important that we provide some guidelines as to when it is appropriate for an action to specify an enablement criteria vs. a visiblity criteria.
In general, visibity criteria should only be used for "static" state where as enablement criteria should be used for state which is expected to change.
The goal here is to present a stable UI to the user. 
Menu items which enable/disable in response to state changes can be understood by the user. 
But menu items which come and go create a "loss of context". 
We want to avoid the user fruitlessly looking for and action which "I know I saw here somewhere". Finding a disabled actoin is much nicer since it ends the search and makes the user think about why it is disabled rather than where to find it.

On a related note, once a plugin is loaded all of the enablement can be done in code. Is it possible to do the same for visibility? One case I think of is a plugin which wants to add an action to only certain type of Java methods. This sort of deterimination can typically only be done in code.

"David Springgay/OTT/OTI" <David_Springgay@xxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx 11/29/01 07:52 PM Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-ui-dev] Changes to action enablement

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