Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Changes to action enablement

Enablement is important for every action extension type, including window,
view, editor, and popup menu.  Visibility only applies to popup menus,
where the popup menu action must be targetted to a specific type.

Currently the platform does not consult the popup menu action delegate
(IObjectActionDelegate) to see if the action should be visible.  It might
be an interesting option, but I have no desire to add it unless somebody
specifically asks for it.  It would probably necessitate the creation of a
new interface, something like IObjectActionDelegate2.


                    "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    
                    11/30/01 10:18 AM                                                                      
                    Please respond to                                                                      

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
In general, visibity criteria should only be used for "static" state where
as enablement criteria should be used for state which is expected to
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

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


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

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.


Back to the top