[platform-ui-dev] Re: RFC: Key Bindings Proposal (end date = Dec 14, 200

["Randy Hudson" <hudsonr@xxxxxxxxxx>]

I understand the value of defining a "pool" of action types and their key
bindings.  And, of course, replacing all of the key-bindings for these
action types with sets like EMACS or Locale/keyboard-specific settings
makes great sense.

As a plugin developer, I should be able to either programmatically lookup a
keybinding for a type such as "go to end of line" either programatically or
in my plugin.xml.  However, it is unclear whether the proposal solution is
to place even more global actions on menu's like "Edit".  I think this
would be a mistake.  There is already a problem in the workbench with
global actions consuming accelerators that controls like text fields would
normally receive.  For example, if "go to end of line", then End key, were
on the Edit menu, then I could no longer use it in any Text field in
Eclipse.  This is why I feel (and maybe it is written as such already) that
a key-bindings dictionary should be available to plugins and their editors,
but nothing more than that.  Well, I guess you would need a UI somewhere to
change the current dictionary used.

USE CASE FOR CHANGING KEY BINDINGS IN ECLIPSE:
----------------------------------------------------------------------------------------
I have been a Leapfrog user for almost 2 years now.  When I first started
using it, I was confused by some of the accelerators it defined.  For
example, F9 was "run to cursor" in VA-Java, but in Leapfrog it was
"Terminate Thread".  You can imagine I didn't have to hit F9 too many times
before I unzipped iveide.jar and updated
com/oti/defrogger/presentation/Debugger.properties.  Ctrl+R was "revert to
saved", which was something I thought needed no accelerator.

One could argue that the defaults weren't perfect for someone who was
familiar with VA-Java.  However, the defaults will never be perfect for
every user.  There *has* to be a way to change any accelerator that appears
anywhere in Eclipse (which turns out to be just the menu bar :-(   ).

I also tweaked various browsers that were specified in XML in Leapfrog.
Eclipse has solved this problem by remembering what the user wants for each
perspective.  I would like to see the same type of support for
accelerators.

RANDY'S IDEAL KEY BINDING SOLUTION
-----------------------------------------------------------------
The pervious proposal focused on what the Editor contributes, but static
Actions have accelerators too.  For example, "Step Over@F6" in the debug
perspective does not come from the Java Editor.

At any point in time, the MenuBar contains a set of Contributions,
consisting of MenuManagers and ActionContributions.  It should be possible
to take a snapshot of all of the contributions on the menubar, ignoring
whether they came from EditorActionBarContributors or somewhere else like
extension-points.  Then, some popup UI would allow the user to override/add
acclerators for the ActionContributions in the menu.  The user override
would be stored in the eclipse.ui METADATA directory as a map from
menuContribution.getId() -> accelerator.

Whenever the Workbench asks a MenuContributionItem for its accelerator, it
would first look for an override entry, using it if found.

Advantages:
1) The user has complete and consistent control over the any action,
regardless of who put it there and when.
2) Editing the accelerators is limited to the current scope of whatever the
user was doing when he/she invoked the menubar customizer.  Alternatively,
if you had a global accelerator customizer (on a preferences page perhaps),
it would present way too many actions for the user to know what they meant,
and it isn't even possible to gather up all of the actions that an Editor
might put in the menu.
3) The user-data that get persisted could be expanded to other things, like
whether that action appears in the menu at all, or whether it should be
presented in a non-default location.

I have ideas to solve some problems that arise with this solution, if
anyone wishes to pursue it.  For example, both HTML editor and Java editor
define Ctrl+I to be indent, and the user is in the Java editor and maps it
to something else.  Does the indent action for the HTML editor get
re-mapped as well?

I think this proposal is separate and almost disjoint from the previous one
that focused on Editor keyboard bindings.  In fact, I would like to see
both implemented, but mine first <g>.





Excerpt from proposal:

The workbench will provide an extension point that a plug-in developer can
use to register a set of key bindings. For example, there could be one for
the emacs editor that would list the accelerator keys to use. The user will
choose the set to use from the Preference dialog.

The key bindings will be defined using XML. There will be support to
specify the platform and locale for a group of key bindings. If the
platform and locale is not specified, then the key bindings will apply to
all platforms and locales. The accelerator key to use for a known action
will be specified as text and will be language neutral. That is, the
workbench will be responsible for translating the accelerator key text for
the user's locale and displaying it to the right or left of the menu item
label.


The workbench will provide a list of "common" action ids. This list will
include:

- all "global" actions like Save, Close, Cut, Copy, Delete, Find, etc.
- all navigation actions like Switch to Editor, Next Editor, etc
- all build actions
- all editor actions applicable to most editors like "go to end of
document", "go to next word", "increase indent", etc

An editor developer will associate actions with these common action ids if
applicable so that the editor actions use the correct accelerator key
defined in the active key binding set. A plug-in developer can define key
bindings for these "common" action ids using the new extension point
described above