[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Re: RFC: Key Bindings Proposal (end date = Dec 14, 2001)
|
See SA> Comments below...
Simon :-)
"Randy Hudson"
<hudsonr@xxxxxxxxxx> To: platform-ui-dev@xxxxxxxxxxx
Sent by: cc:
platform-ui-dev-admin@e Subject: [platform-ui-dev] Re: RFC: Key Bindings
clipse.org Proposal (end date = Dec 14, 2001)
12/11/2001 10:59 PM
Please respond to
platform-ui-dev
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.
SA> The plan is not to add more menu items to the Edit or other menus. The
editor still decides what action goes there (above what the Workbench
already contributes).
SA> Thanks for pointing out the case about global actions consuming keys
the text field may want. I need to add this to the doc so as not to forget.
The way I see this working is if there is no action "registered" for the
key binding, then the key is sent to the widget for processing.
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 :-( ).
SA> You are correct, what I think is a good accelerator key for an action
is considered annoying for someone else (and vice versa). The Key Binding
Set proposal addresses most of there problems. For example, someone could
provide a LeapFrog key binding set so developers used to working in that
environment will feel somewhat at home in the various Eclipse editors and
tools.
SA> This proposal does not address the problem with the user being able to
define any accelerator key on a per action basis. There will be another
proposal for that because there are many issues to be looked at. Putting it
into one proposal was just too big.
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.
SA> Given that the action has an id in the Action Set, the developer of a
key binding set can reference it and assign an accelerator key to it. So
you could have someone produce a key binding set called "Leapfrog" that
would map actions in Eclipse to the accelerator keys that would be used in
LeapFrog.
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>.
SA> These suggestions and comments will be perfect for when we put together
the proposal that allows the user to edit accelerator keys on a per action
basis. We will consider your ideas - I have to admit I had not thought
about this approach. It is interesting and worth looking into when
preparing the next proposal for user custom changes.
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
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
