[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] re: action contribution
|
Just to add one more thing. The method IAction.setAccelerator(..) should
be deprecated as well.
Eduardo.
"Chris McLaren" <Chris_McLaren@xxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
11/20/2002 04:29 PM
Please respond to platform-ui-dev
To: platform-ui-dev@xxxxxxxxxxx
cc:
Subject: [platform-ui-dev] re: action contribution
Responses to questions from Kai-Uwe Maetzel, posted 11/18/02 07:02am:
>How do I register an action contributed by an editor action bar
contributor
>for dynamic key binding?
For the org.eclipse.ui.editorActions extension point, you can add a
'definitionId' attribute for each action declaration. it has not been
updated
in the documentation yet, but it exists and is currently the recommended
approach.
>Besides the above, what do you recommend for contributing actions in
>general? This covers menu bar contribution, retargeting, key binding
>participation, and accelerator specification:
>Currently, when putting place holders (RetargetActions) into menus, they
>can be linked to concrete actions. For that, the concrete action must be
>registered as global action handler under the place holder's action id.
The
>action id identifies the particular action instance representing the
place
>holder. Any action that should participate in dynamic key binding must be
>registered with the key binding service under an action definition id.
The
>action definition id defines an abstract action type such as Save or
>Rename.
All of this is correct.
>As a plug-in developer, I tend to register all my actions with the key
>binding service in order to achieve customizability. Thus, my actions get
>set an action definition id. Also, I tend to register them as global
action
>handlers as I want to decouple decisions about my menu bar structure from
>the implementations of my parts. For that I have to know the action id of
>the place holder. As I know the action definition id anyway, this usually
>leads to a design where the action id of all place holders is the same as
>their action definition id. Action definition ids appear in the action
>declaration part of the plugin.xml files. This sustains the decoupling.
Your analysis correctly reveals the current strangeness of our action
story.
Because we now have action definitions, the notion of retargetable actions
is
somewhat, but not completely, superfluous. With some thought, retargetable
actions
should be phased out eventually. We can't do this yet, of course, because
we
do not yet have the ability to assign action definitions to positions on
the menu.
Designing keybindings around the action definition architecture was a
first
step.
A next step would be customizatable menus/toolbars based around action
definitions.
>Based on this scheme, it seems useful to free client code from the need
to
>know about the intrinsics of retargeting and dynamic key binding. It
would
>suffice if the client registers its actions with its part site. The part
>site would then set the action as global action handler and register it
>with the key binding service. As a side effect the workbench could change
>related code without affecting clients.
I apologize, I don't exactly understand this paragraph.
>Actions can be put into the menu bar via code (such as the editor action
>bar contributor) or XML. Using XML the actions seem to automatically be
>registered with the key binding service. In the first case, the
>registration must be done in code. What's the general scheme to do this?
>(See my first question.) Is XML or code the recommended way in respect to
>decoupling, maintenance, and scalability? It seems to me that focussing
on
>XML would simplify things.
XML is the correct way to do this. All action definitions should be
defined
in
XML.
>Most property files contain the action name and the default accelerator.
>Typically, the accelerator is also specified in at least one key binding
>in the plugin.xml. Can I remove the accelerator specification from my
>property files?
Yes! Definitely. All accelerators in property files should be removed. As
well, the
'accelerator' attribute for actions is deprecated in all places. We might
as well
remove these from the XML as well. Again, the documentation has not yet
been
updated yet to reflect this.
Chris.
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
