[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] re: action contribution
|
Thanks for your comments. See <kai> for additional thoughts/clarifications.
Kai
"Chris McLaren"
<Chris_McLaren@xxxxxxx To: platform-ui-dev@xxxxxxxxxxx
> cc:
Sent by: Subject: [platform-ui-dev] re: action contribution
platform-ui-dev-admin@
eclipse.org
11/20/2002 10:29 PM
Please respond to
platform-ui-dev
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.
<kai>
When specifying actions in XML the workbench automatically registers them
with the key binding service. As you are saying below, XML is the way to
go, so this is perfect. However, given the current code base I am
interested in whether there is a way to do this in code or not. An editor
action bar contributor owns action instances each with action id and action
definition id. The contributor is special as it is not a part but
represents an open set of parts. How does the contributor get access to a
key binding service to register the action instances?
</kai>
>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.
<km>
I believe that the decoupling of parts and their actions from the menu
structure as described above should reflect in the API. Parts should only
know about their own actions and a place to register them with the
workbench. The part site seem to be a good choice for this place. The part
site would then register the action as global action handler and register
it with the key binding service. Parts would not have to be aware of key
binding services or action retargeting, it would just happen for all of
their registered actions.
</km>
>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
