[platform-ui-dev] Comment on RFC Keyboard-Binding proposal.

[manahan@xxxxxxxxxx]

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
_____________________________________