[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Comment on RFC Keyboard-Binding proposal.
|
The proposal for Key Binding does not deal with the user specifying
accelerator keys via the ui - that will be addressed in another proposal.
However, I can say that the user's accelerator key changes done in the ui
will most likely be saved as a custom key binding set.
The key binding is developer centric in the sense that only developers who
know how to add an extension will be specifying key binding set. Maybe
someone will provide a plug-in to do this visually?
Each editor developer is not required to produce a key binding set.
Actually, the developer providing a key binding set is probably not
providing any views/editors. For example, if you know how to add an
extension in a plug-in, then you could write the XML for the LPEX key
binding as a plug-in
Maybe one point that you may not have seem or understood. A user will be
able to choose which key binding to use based on what sets are installed.
So there could be the Defaults, Emacs, Brief, VI, LPEX, etc. Maybe even one
for accelerator keys from another IDE for migration purposes to Eclipse.
Once selected, all editors will use these accelerators. Say the user
chooses emacs key binding set. Then the JDT Java editor will have its save
action invoke when Ctrl+X Ctrl+S is pressed. Same for the WSAD HTML editor,
workbench default text editor, the PDE editor, etc
It is important to note that editors will just be providing actions like
they always did. These actions can have an accelerator key. However, the
accelerator key defined in the key binding set will override the
accelerator key that the editor provided (unless of course the action id
does not map to the key binding set).
Your example of "inheritance" of key binding set is what we plan to do.
Simon :-)
manahan@xxxxxxxxxx
Sent by: To: platform-ui-dev@xxxxxxxxxxx
platform-ui-dev-admin@e cc:
clipse.org Subject: [platform-ui-dev] Comment on RFC
Keyboard-Binding proposal.
12/11/2001 03:44 PM
Please respond to
platform-ui-dev
Hi,
After reading the proposal it seems that the KeyMap Set implementation
is developer-centric (those developing for eclipse) rather than
user-centric (those using eclipse). Since the user's can't really modify
the mapping it requires that each developer of an editor(for example) would
have to know the bindings of the editors that the users are most
comfortable with. I know for fact most developers don't know bindings for
the editor I am most comfortable with, which is LPEX.
Have you considered more of tree/set combo approach rather than a pure Set
approach? Something like next bit.
Sets of "common" keybindings can still be created if you associate a key
with a set. And allow the developer to add the set to his bindings
<keyset name="commoneditorBindings" style="default">
<keysetbind actionId = "org.eclipse.ui.common.saveaction">
<key accelerator = "Ctrl+S"
// I believe that the translation should be separate from the
actual Id and perhaps should be in separate file
accleratorId="CTRL+S"/>
</keysetbind>
</keyset>
Below shows a common set with a mode key Ctrl+X. There are several ways to
dot this, an alternate to what is below is to have the Ctrl+X have a "mode
switch" action of which the "Crtl+S" binding for org.eclipse.ui.saveaction
is a child.
<keyset name="commonEditorBindings" style="Emacs">
<keysetbind actionId="org.eclipse.ui.saveaction">
<sequence> // you could also just next the key's i believe
but this i think makes it clearer to read
<key accelerator="Ctrl+X" acceleratorId="CTRL+X"/>
<key accelerator="Ctrl+S" acceleratorId="CTRL+S"/>
</sequence>
</keysetbind>
</keyset>
For users overriding keysets( below we have selected the emacs keyset for
our use but prefer the Ctrl+S as a save action.
<keyset name="commonEditorBindings" style="Custom" default="Emacs">
<keysetbind actionId="org.eclipse.ui.saveaction">
<key accelerator="Ctrl+S" acceleratorId="CTRL+S"/>
</keysetbind>
</keyset>
You could potentially add editor specific overrides as well.
There should be a strict hierarchy of where to find the action
<default set> // basically the workbench defaults
<developerset> // like emacs for instance, developers can only use
sets for common actions
<customset> // the users custom set
Where the customset overrides, developerset and defaultset and
developerset overrides the defaults etc.
I modified the pro's and con's to add some more pro's :)
pro: a plug-in developer can define the accelerator key set for any
preferred editor, like emacs.
pro: support for platform, local, and keyboard differences
pro: addresses most of the issues (I offhand don't see one it doesn't
but there is bound to be one)
pro: users can make up their own sets and are not limited to the sets
provided
pro: users can change a specific action accelerator key thru the UI (
this perhaps is a staged thing>
con: trying to identify these "common" actions for all editor types
( I believe this is best initial effort basis and perhaps over time a
list can be built up)
con: editor developers will need to associate their actions with the
applicable "common" ones
There are still many holes here but perhaps it provides more food for
thought.
Thanks,
_____________________________________
Peter Manahan
WSAD Linux Port Team
VisualAge for Java Release Lead
manahan@xxxxxxxxxx
_____________________________________
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
