Community
Participate
Working Groups
Improve keyboard bindings. Several things should be done to improve keyboard bindings. First, custom key bindings currently work only in the main Eclipse window, and not in secondary windows like dialogs, wizards, and floating views (another plan item). For example, custom editor key bindings do not work in a text control in a preference dialog. Eclipse should support custom key bindings in the places where the user reasonably expects. Second, the key customization dialog should be improved. Finally, make a systematic pass through the UI to rationalize the initial set of key bindings. [Platform UI, SWT] [Theme: User experience]
*** Bug 37669 has been marked as a duplicate of this bug. ***
Some other requirements: - Help the user learn the keybindings: provide the option to show key bindings on context menus, show key bindings in toolbar tooltips, be able to display/print a list of the current key bindings, etc. - Allow the user to create new key configurations, and import/export them independently of other preferences.
More requirements: 1) The workbench should support multiple, orthogonal key configurations. For example, for a WYSIWYG HTML editor (or any other non-source editor), "emacs" configuration makes no sense. They would instead want to define configurations for other HTML keybindings, such as FrontPage, DreamWeaver, etc. The user should be able to activate simultaneously the "emacs" mode for the Java editor, and the "frontpage" mode for the html editor. 2) The keybinding preference page does not scale. The user should be able to filter the values displayed by configuration, scope, and editor type, such as HTML editor.
FYI: A draft proposal for 'Contexts' has been posted to the Platform UI proposals page at: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/docs.html. It is expected that contexts will form *a small part* of the solution to this plan item. (see section on 'Key Binding Scopes' for details).
Should provide other common key bindings out of the box, especially Brief w/CUA extensions
Created attachment 6939 [details] Proposed Key Bindings (DRAFT) This is a very rough proposed list of new key bindings for Eclipse that address some of the problems with consistency across platforms and locales. It also clears out some space for more key bindings -- if teams would like to use it. This addresses the second part of this plan item. We are working toward providing this key configuration as a new key configuration in Eclipse, which will allow developers and users to try the configuration and provide feedback. In the final 3.0 release, we envision this current set of key bindings being available as one of the configurations, but that this key binding set would become the default. Again, it is a very rough draft, and will almost certainly change. Feedback is very much appreciated.
Created attachment 6940 [details] Proposed Key Bindings (DRAFT) Switched "Resume" from "Ctrl+Shift+Y" to "Ctrl+Shift+M" after examining international keyboards. The "Ctrl+Shift+" debug sequences are meant to be close to each other on the keyboard. Unfortunately, this is not the case in the following locales: + Latvian + Turkish There might also be problems on: + Arabic + Hebrew
My first reaction is that adding so many two-key sequences adds a lot of complexity for the user, both to type and to remember. They will probably also require significantly more space to show in the menus. I think two-key sequences should be the exception rather than the rule. I also don't think we can come up with a major improvement to the bindings without considering what some of the larger Eclipse-based products are doing as well. This should be done in conjunction with the usability team. For example, there may not be any strong requirement to reserve Ctrl+B globally for Bold. An editor which wants this binding can define it in its own scope. Also, there are some industry standard keybindings for debugging. The ones we have now are inherited from VA/Java, which is non-standard. I believe that VS, IBM's Distributed Debugger, CodeWarrior, and some other dev envs use the same keys for debugging.
I think the VA-Java keybindings for debugging are the same as Borland C++ 4.0 keybindings from way back when. What are the current industry standards for these action? I like the current ones just fine. BTW, debugging might be a good example of an orthogonal key configuration. I should be able to choose either "VA-Java" or "Industry standard" configurations. With all the discussion going on, I have not seen what is being done to address the need for multiple user-selectable configurations. See comment 3.
Chris McLaren is working on orthogonal key configurations, and I cannot comment on the direction he is taking. My argument would be that it is actually easier to remember keys when they are grouped in this way. I personally find it easier to remember smaller groups chained together, then one large set with no distinctions or groupings. And, as a minor point for our English-speaking users, the associated letters are much easier to match to the actual command executed. Yes, it does make the menus wider (not so much on Carbon). I'm not sure if there is a good way around that. As for the difficulty in typing, I'm working on a couple of affordances that would might make multi-stroke key bindings easier to type. The argument for not binding "Ctrl+B" comes from the Apple Human Interface Guidelines. Partly, I'm just reserving space for future growth. Don't read too much into the "RESERVED" vs. "UNUSED" distinction. Essentially, unless used, these spaces would give good spots for users to map macros or their own favourite keys. I'm not entirely adverse to the idea of having the debug keys stay on some of the function keys, however, I'm not sure if that is a good idea. There is a very strong argument in "we have been doing it like this for a long time". However, as you can see below, the keys that we have are non-standard (i.e., there is no standard), and cause conflicts with native key bindings. For reference, Microsoft Visual Studio does not use the same key bindings we do. Here is a small sample: F5 Start debugging session F9 Toggle breakpoint F10 Step over F11 Step into Here is a sample from the default key bindings for Borland C++ Builder: F4 Go to cursor F5 Add breakpoint F7 Trace into F8 Step over F9 Run Also, note that Code Warrior does not use function keys for debugging in its Linux and MacOS X versions. Borland C++ Builder and Microsoft Visual Studio are only available on Windows. Also, note that the following keys have reserved meanings in Microsoft Windows: help (F1), rename (F2), search (F3), drop-down list (F4), refresh (F5), and cycle elements (F6), extend selection (F8), and focus on menu (F10). On KDE, the following keys have reserved meanings: help (F1), rename (F2), find next (F3), and refresh (F5). On GTK: cycle elements (F6), focus up (F8), and focus on menu (F10). For better or for worse, this new key configuration will be available in tonight's nightly build (not the integration build). If you are interested if giving them a whirl, please send me your feedback.
I think the idea of using 2 keystrokes is perfectly ok. It would be better if the first keystroke (such as Ctrl+R for refactor) displayed something indicating "refactoring" was in the queue and waiting for its second accelerator. But I guess there is no rule that says CTRL+R must be refactoring. Maybe just showing the queued keystroke(s) in the status line would help. Could a "shorthand" be used in the menus? For example: Ctrl+RV Ctrl+(RV) Ctrl+R,V ^R^V
the nice thing about two stroke key sequences with the same modifier key is that you don't have to release the modifier key between strokes. i think doug considered that when laying out this set. shorthand in the menus is an interesting idea. when shortening Ctrl+R Ctrl+V, for instance, consider that Ctrl+R V is also a possible key sequence. therefore, Ctrl+RV and Ctrl+R,V are probably not a good short forms. as doug said, the mac doesn't have this problem because it uses special single character glyphs for the modifier keys. maybe we can save space this way on other platforms. i.e. use '^' for 'Ctrl' just like on the mac, or 'C-', 'S-', 'A-' for 'Ctrl', 'Shift', 'Alt', etc. i suppose these are worth trying (as a preference? 'Use shorthand for key sequences in menus') I beleive it was in a swing look and feel, or possibly IntelliJ, which used a smaller font (and a different color) to display the key sequence.
I'm just guessing, but I would imagine that 99.9% of all users will not have any accelerators defined of the type Ctrl+R V. Or, if that is normal, why not remove the CTRL modifier from the 2nd accelerator of all your 2-key sequences. problem solved. I think Ctrl+RV or Ctrl+R+V is the right thing to do because it is much easier for 99.9% of users to read the 2 keys which must pressed, and although subtle, it is distinguishable from "Ctrl+R V" I wonder if characters like "¡è" would showup, to indicate SHIFT. Maybe @ or ¨£ for ALT?
its hard to argue with '99.9%' anything. how many were polled exactly? :) i suggested to doug that i'd like to have the second key stroke be an unmodified character - like 'ctrl+r r' for refactor->rename, 'ctrl+r m' for refactor move, reserving modified second key strokes for variants on the same command. doug countered that the second keystroke might be inclined to have the same modifiers (or more) than the first keystroke such that one can keep the modifiers down (or add more) during the keysequence to make it easier to type -they sort of flow more naturally that way. perhaps randy your suggestion of 'ctrl+rv' makes more sense if we use a separator between key strokes that's more than a space - say ',' for instance. then you might have 'Ctrl+R,Ctrl+V' being shortened to 'Ctrl+RV', and i'd argue that 'Ctrl+R,V' is more distinguishable from 'Ctrl+RV' than 'Ctrl+R V' is. (did that make any sense?) just a thought. (that might be a lot of ',' characters polluting the menus - other apps like visual studio use ',' don't they? - though they might use it for separating multiple key sequences to the same command..) in the absense of swt giving us any support for putting a smaller font on the menus for accelerator text, perhaps we could offer the user choices of shorthand (as a preference). for instance, emacs users might enjoy emacs style presentation of key strokes ('C-x'). we don't have this functionality now.
1. a really small (but really nonstandard) form might be use a lowercase letter for the modifier key: e.g. 'cR cV', 'cR csV'. 2. all of these shorthand forms look strange or don't work with any key stroke whose representation is longer than one character. function keys, enter, home/end, page up/down, arrow keys, etc. e.g.ctrl+R ctrl+end wouldn't exactly be shortened to 'ctrl+rend'. (my keyboard has its own special 'rend' key on it for when i have particularly bad days :)
2. Not all of them. Ctrl+R+END looks ok I understood the comma comments. If multiple +'s are used, commas wouldn't really be needed.
Created attachment 6980 [details] Proposed Key Bindings (draft) Yet another draft -- removing the "shift" modifier key from the second part of the two-stroke key bindings, and doing some minor clean-ups.
The new keyboard shortcuts are available in today's integration build (I20031202). They are called "Standard (3.0) - NEW!" in the "Active configuration" combo box on the keys preference page. Under the advanced tab are two user affordances. The first check box turns on a dialog with the possible completions that appears after a delay. The second allows you to press "Ctrl+K+F+O+S" and have it mean "format, organize imports and sort members".
i've been working with these today and i noted something interesting about usability, at least particular to myself.. while 'Ctrl+X Ctrl+Y' might seem like a useful pattern because one can 'pivot' on the Ctrl key (not releasing it over the course of the keystroke), i was surprised to find that i'd rather release it an press a single character as the second keystroke when possible. it actually seems a little awkward to do this. i think this is because the holding of a modifier between regular keys feels wrong. its not the way we type anything else, except for one use case that i can think of: for some of us, that when editing a document, we ignore the caps lock key once in a while and hold shift down to make multiple capital letters in a row - and it feels awkward to me each and every time i do that. anyway, this is just one guy's opinion, but if others find the same thing to be true, i'd suggest changing the default pattern to 'Ctrl+X Y'. this would have two advantages: a) it helps with the menu text length problem we've been discussing b) it opens a wider domain for key strokes for variant commands
I've been working with the new keybindings for a week now... my impressions: 1. Multiple key stroke bindings - good in areas where a larger interaction (dialog, wizard etc.) is expected and I never do it repeatedly: Refactoring and complex formatting commands. The nice thing is that it groups the commands together, with the optional hint. - however, really no big improvement over using Alt+${Menu Mnemonic} ${Command Mnemonic}, e.g. 'Alt+T N' for the rename refactoring. This way I get the grouping and the hint without additional ui. - awkhard or almost unusable for commands I use often and are very fast - All debug bindings (have to use both hands to step!) - quick fix - navigation (go to last edit location, quick outline, go to line!) - incremental find - text editing (delete line!) - go to next previous (must be first class citizen, not Ctrl+Shift+N/P) - awkhard where I have to press multiple times: - next / previous editor (try pressing Ctrl+Shift+E a couple of times) 2. Display of multi stroke bindings (see comment 19 and above) - The modifier must be repeated, whether abbreviated or not. Emacs uses a whole lot of bindings that exists in in a version with the second key modified or not. Exp: 'C-x C-s' is 'save, 'C-x s' is 'save all'. 3. Industry standard adoption - Makes sense where we are like MS Word (Alt+F4, F10, F1...) - Doesn't make sense for commands we never use: - Ctrl+0 for 'open external file' is wasted - you never do that! - Double bindings seem wasted: - Ctrl+Q (use Alt+F4) - F3 (use Ctrl+G, which is symmetric to Ctrl+Shift+G) 4. Varia - why do we have to 'leave room' for other applications? If WSAD adds more functionality on top, they are likely to not need some of the base stuff any longer and can reassign the bindings, can't they?
a couple of opinions from me: (though Doug is the guy working on the set of bindings) MENU MNEMONICS: i disagree for three reasons. 1. menu mnemonics are not available on all platforms (mac, for one..) 2. menu mnemonics always cause the menu to show which is visually distracting. the hint is not optional in this case, and the hint is to show the menu, which is not (generally) the same as showing the set of possible completions. 3. menu mnemonics first stroke is always represents the top level menu - no remove for categorizing further. (arbitrary e.g. Ctrl+P to begin key sequences for 'printing', as opposed to 'Alt+F' because they are on the file menu) COMMANDS USED OFTEN OR MULTIPLE TIMES: i agree. we need to do something about this. doug can take this feedback and shuffle the assignments bit, but i still think we will run out of keys. we still need to consider (scopes/contexts): that when debugging, for instance, F5, F6, F7 take over. (or some other set of easy to use keys). doug's current set is ambitiously context-free. DISPLAY OF MULTI-STROKE KEY BINDINGS: i agree. i would like to use a set where the second key stroke is usually unmodified. not only is the display in the menu shorter, but we get a lot more possible key sequences if we don't force the second key stroke to carry the 'ctrl+' modifier all of the time. (unmodified, ctrl+unmodified, shift+unmodified, alt+unmodified, etc.)
- Good point about the mnemonics. And I must say that the optional hint is very lightweight and makes learning new keystrokes a no-effort. - Repetition of modifiers in multi-stroke bindings: as opposed to chris' comment 19, my personal preference seems to be to repeat the modifier for the more common cases, because it types faster. However, if the most frequent commands are moved to single-stroke bindings, this might not matter so much any more.
I tried the new 3.0 standard key definitions, and for me they're less useful than the default definitions. For example, the combination ^J^L for go-to-line is difficult to remember and too many keys for a commonly used task. I may as well use Alt-ngg to navigate the menu. The same applies for the next annotation command. I think a useful rule of thumb would be that when a key binding is one keystroke away from being as complex as the effort required to navigate to it using alt and the menu, it's no longer useful. From an ergonomics standpoint, key commands that require holding down multiple keys are hard on the hands, so for me, moving from simple commands like ^. to Shift ^n is not an improvement. I think the ergonomic concerns should outweigh any mnemonic efforts. Repeated commands will be memorized quickly, while ergonomic factors will have long-term effects. I would suggest mapping fewer of the commands by default but making sure that all activities are mappable. I would also recommend leaving a few keys unmapped for users to create multiple keystroke mappings without upsetting the default mappings for keys. I'd like to get a listing of all key bindings broken down by mode and be able to list all the available keys for simple mappings so that I can make my own assignments without creating conflicts. JEdit has a reasonable interface and set of macros to deal with this task. Here's an example. I would really like to be able to switch to the Team Synchronization perspective, expand all folders with modified files, navigate to each file in turn, see the differences in a given file, and commit the file using only keystrokes. I'm missing expand all and commit, which I can't bind. Ideally, I'd want to bind ^C to commit in the Synchronize view, since I'm never going to use cut there, and ^E to expand all. Worst case, I'd like to use ^W to at least bring up the view's menu and select the commands with a single keystroke. While trying to do this, I used the Keys configuration panel and looked at both the CVS and Team Categories in the drop-down. It doesn't look like the Name pulldown changes when I go to Team, so I'm not getting any Team possibilities. I can't figure out how to map the context menu. A better interface might let you select the category and list all key assignments in the table below. Then, it would have add/edit/delete buttons for bindings which you could select in the table. The add and edit buttons would bring up a pop-up that would let you select the command, binding, and context, and possibly search for existing bindings as with the key sequence panel. This functionality appears to be in the current interface, but it's not clearly interrelated. I noticed while looking into this that Alt minus is no longer displayed in Show System Menu under Keyboard Shortcuts in the Window menu. I'm getting a hex character. I hope these suggestions are helpful, and I appreciate your work on Eclipse.
Rather that guessing what commands are commonly used, it might be better to have an opt-in configuration to mail back command useage statistics. It might only be available to CVS or milestone users and maybe once a week mail off a file or serialized object containing a tally of each command that was used. With the data you could map the bindings to commands based on ergonomics (easiest to reach keys with the strongest fingers), mnemonics, or convention. The top 26 commands could be mapped to single key-strokes, the next 26 with modifiers, and so forth.
Are there any plans to address comment 3? An alternative UI for editing keybindings would be to exchange the "category" and "when" displays. Currently, the user is overwhelmed with every single category and action. You must first pick a category, and the "context" is secondary and is displayed as a table column. This makes simple tasks like remapping code assist, or overriding a keybinding for a particular "when" difficult. As a user, I would rather see a tree of contexts such as: + Default |-+ Editing Text | -+ Editing Source | -- Editing Java Source |-+ Debugging | ... |-+ Editing HTML ... When I select a given context, I can see all of the categories and actions associated with that context, excluding the inherited actions (or perhaps there is a toggle button to show all inherited?). Then, give me buttons to do things like: a) find an action (in the current context) by name. Sometimes the category is not obvious (like source vs. text) b) Show me what a given keybinding does in the selected context. The current UI shows me current assigments in contexts which don't actually conflict with what I am doing, so the information is just getting in the way. c) Override an inherited keybinding. For example, in the "Editing Java Source" context, I might want to override some action from "Editing Text" to another or null keybinding. This is currently a very complex task.
Created attachment 7490 [details] Debug options providing information about keys The old key bindings draft is now obsolete. Start Eclipse with these debug options to get a message printed to stdout every time a key binding is matched.
Created attachment 7491 [details] Batch file for key information Start Eclipse with something similar to the following to get information printed to your home directory in a file called "eclipse-output.txt".
Created attachment 7492 [details] Shell script for key information Use this shell script (or something similar) to start Eclipse under Linux. This will give a file called "eclipse-output.txt" containing information about the keys you have used.
While it would be nice to use the instrumentation plugin for this, there is still some work to be done before that is possible. Instead, I'm asking people to run Eclipse with the given debug options file, and send me the output it generates. You can either attach the output to this bug, or reply to me personally via email ("douglas.pollock@magma.ca"). My hope is that this will give us more information about which key bindings really are used the most frequently. We will adjust the new key configuration appropriately. So, please help out and send in some info! Thanks....
See also bug 53402.
The new keyboard bindings have been pulled due to lack of time to complete the task. Key bindings in dialogs are almost ready (probably by M8). The key customization dialog will likely be worked on during M9. The initial set of key bindings has been reviewed, and I believe we're fairly happy with what we have.
Added new bugzilla for comment 3 item 1).
overall this is done
The keybinding preference page was not updated. It's still about as usable as a bowling ball without holes. Is there a separate bugzilla tracking this?
Randy: Bug 43506
