Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-ui-dev] Re: Action Enablement

Hi All,

Dirk has asked me to make this discussion more public.  It is focused on
action contribution and enablement.  To start, he had a question about
IActionFilter.  An action filter is used to control the visibility of popup
menu extensions in the product (but soon it will be used as a general
mechanism for enablement of all actions ).  Here is the java doc ..

 * Within the workbench a plugin may extend the actions which appear in the
 * context menu for any object.  The visibility of each action extension is
 * by action filtering.  By default, the workbench will filter each action
extension using
 * the <code>objectClass</code> and optional <code>nameFilter</code>
attributes defined
 * in xml.  If the action extension passes this test the action will be
added to the
 * context menu for the object.
 * </p>
 * <p>
 * In some situations the object class and name are not enough to describe
the intended
 * target action.  In those situations an action extension may define one
or more
 * <code>filter</code> sub-elements.  Each one of these elements describes
one attribute of
 * the action target using a <code>name value</code> pair.  The attributes
for an object
 * are type specific and beyond the domain of the workbench itself, so the
 * will delegate filtering at this level to an <code>IActionFilter</code>.
This is a
 * filtering strategy which is provided by the selection itself and may
perform type
 * specific filtering.
 * </p>
 * <p>
 * The workbench will retrieve the filter from the selected object by
testing to see
 * if it implements <code>IActionFilter</code>.  If that fails, the
workbench will ask for
 * a filter through through the <code>IAdaptable</code> mechanism.  If a
filter is
 * found the workbench will pass each name value pair to the filter to
determine if it
 * matches the state of the selected object.  If so, or there is no filter,
the action
 * will be added to the context menu for the object.
 * </p>
 * <p>
 * The attribute names for <code>IResource, IMarker and IProject</code> are
 * in <code>IResourceActionFilter, IMarkerActionFilter, and
 * </p>

For more information, see my latest article on views in Eclipse Corner.

Look for the section titled Supporting Extension of the Context Menu: The
Problem Case

For further notes, see DS> in the email below.

----- Forwarded by David Springgay/OTT/OTI on 11/28/01 09:22 AM -----
                    Dirk Baeumer                                                                  
                                         To:     David Springgay/OTT/OTI@OTI                      
                    11/28/01 05:22       cc:                                                      
                    AM                   Subject:     Re: Action Enablement(Document link: David  


now as I understand the use of IActionFilter a couple of more issues pop
into my mind. The following statements are based on the assuption that we
*only* use object contribution to contribute to context menus and that we
use action filters to filter them out.

- how do we avoid menu cluttering. Lets say I have ten plugins installed
that contribute actions on IResource. I then end up with a large context
even if I don't use any of the installed plugins. And how do we control the
ordering in the context menu in this case. IMO users are very sensitve to
what shows up in menus. Both extrems "not showing actions I need" and
"showing a lot of actions I am not interested in" are not what users want.
Consider the following example: I have a Java and a C plugin installed. The
C plugin contributes some actions to IResource. The Java plugin has
implemented an adapter that converts Java elements back to IResources if
possible. As a result all the C plugin actions show up in the context menu
of my Java views. I strongly believe that this is not always what a user
wants, especially if he is currently working on a Java only project. As you
always point out, persepctives are means to define the context for a task.
Logically there should be a filter mechanism for menu actions per

DS> Good question.  In our proposal, we address menu contribution,
overload, and ordering.  In particular, we will extend the existing xml for
the 4 action extension points: popup menu, view, editor, and window.  In
each case, the xml will support fine grained enablement and visibility (for
popup menu actions).  You will be able to describe your target using class,
or other type specific actions.  For instance, you can reference any of the
resource attributes defined in IResourceActionFilter, including name,
exension, read-only state, and project nature.

We also plan to tweak contribution, so that you no longer need to define
your action extensions in the reverse order.  This will be a non breaking
change.  And we hope to encourage the definition of a standard set of
groups, or at least encourage people to publish their groups in a more
visible way.

- how do we handle the case of equal named actions that do different
things. In the Java perspective we already have this problem. Here we
contribute actions to  Java elements that can be converted into IResources
(using an adapter). As a result we now get the Replace from ... VCM actions
"for free". But for an IMethod we want to contribute a special Replace from
... action that compare the files in the VCM system and only show those
method that are really different (like replace from local histrory).
Additionally how do we handle the case of different rename actions (Rename
from the outliner on IResource and "Refactoring Rename" in JDT).

DS> We are aware of these problems, and plan to address them in our next
iteration of the action extension code.  Log the PR's so we know where our
failures occur.

IMO the content of a menu must be under the control of a user and/or
influenced by the active view part and perspective. For example in a search
result view that present Java elements I am not interested in seeing all
the VCM actions. I would expect support to quickly naviagte to a view that
allows me to do the VCM actions on that element.

DS> May be.  For now, we believe that the object attributes are enough to
perform good action filtering on an object.  We are currently developing a
set of UI guidelines which ISV's can follow, to ensure good menu extension.

Some implementation issues:

- using IActionFilters seems to be more difficult (from an implementation
perspective) than contributing an action in code. I am not sure if
everybody will handle the two "indirections" correctly (separate object and
key/value pairs).

- executing an action from a context menu could trigger a plugin load. If
this happens the workbench should at least give some feedback to the user.
Otherwise he may think that the workbench crashed when plugin loading takes
a time. In my opinion users do not expect a large delay when executing
actions from a context menu.

Some general notes:

- regarding layout issues the workbench always proposes that the user
should be under full control. But regarding menu content or which plugins
should be loaded on startup we don't want to give any control to the user.
Might be that some problems could be solved easier if we give the user more
control over these issues too.

- I find this dicussion very valuable for others. Do you mind if we
continue this discussion on the mailing list


                    Springgay            To:     Dirk Baeumer/ZRH/OTI@OTI                         
                    27.11.2001           Subject:     Re: Action Enablement(Document link: Dirk   
                    16:59                Baeumer)                                                 

Hi Dirk,

You wrote ..

Regarding IActionFilter: I am not 100% sure how they work, may be thats the
reason why we don't use them. So may be you can shed some light on it.
Consider the following example: I have an IMember and I only want to
contirbute an action if the element is not read-only. If I implement an
action filter for it and make an object contribution with this action
filter for IMember how to you avoid loading the JDT plugin, which actually
implements the action filter, when a context menu on a IMember is
requested. Or are only those action filters considered for which the plugin
got already loaded.

If the action in the window menu is contributed by the plugin providing the
view or editor, the action delegate should be created.  Once this occurs,
it will control its own enablement.  We are mainly concerned with actions
which are contributed by plugins which have not been loaded.

If the action is contributed by another plugin, we would like to defer the
loading of that plugin until the action is invoked.  In this case the
plugin providing the view or editor has been loaded, and can provide the
action filter for the IMember.  This action filter may support filtering on
things like read-only, type (field, method), visibility, etc, which reflect
the selection type.

For more information, see my latest article on views in Eclipse Corner.

Look for the section titled Supporting Extension of the Context Menu: The
Problem Case


Back to the top