Community
Participate
Working Groups
I'm using the new keys preference page for the first time and was a bit confused. I was trying to assign keys to some of the new Team commands that I've created. When browsing command names the bottom key sequence fields are not kept in sync. I was confused that the key sequence was actually the *keys* assigned to the selected command name. But I was wrong, the assignments just below show that. But note that the language between the two groups are the same and can lead to confusion. suggestion: Clear the key sequence selector group box when a new command is selected.
On another note, I was playing around with another IDEs (cannot be named) and really like their key binding page. I find the layout they have selected really works because you can easily see the association between commands and key bindings. Then the area to select a new key is separate. Also, it supports mnemonics in menus! Cool! Anyway, the page has a tree table with first column shows Commands (hierarchical), and the second the Shortcuts. The bottom of the dialog is where you add/delete shortcuts. It also supports mouse shortcuts.
addition usability comments from 42041: #7 From Daniel Megert 2003-08-28 10:10: ... - before I noticed the coolness I tried to enter the shortcut via character keys and not using modifiers. After entering Ctrl (which appeared as "CTRL") I was not able to enter the "+" and I did not get any feedback that would bring me on the right track - with the new UI it is harder to get an overview of the available commands. This was easier with tree than with the two drop downs. #8 From Chris McLaren 2003-08-28 10:58: ... re entering key sequences: yes, perhaps a text on the dialog that tells the user to enter the key sequence directly, which perhaps throws up a warning icon and alters the text somewhat when the user types in unmodified characters. (people wouldn't intend to bind to a single unmodified letter for instance; that letter would be unusable in the editors.) re: tree vs. dropdowns: this was a concerted effort to reduce the size of the keys preference page, which i believe had the dubious distinction of being the largest preference page in the 2.1 release. (currently, on the mac at least, i'm a fair bit smaller than java editor pref page.. :) #10 From Gabriele Garuglieri, 2003-09-01 08:00: May i dissent on the choice of drop down menus vs tree view? I completely agree with Daniel Megert, there are so many choices for categories and names within them that unless you have the keys tree well cast in your mind, like perhaps you developers have, finding an action without knowing in advance to which category it belongs, is a real pain. And not speaking of the fact that the tree view was giving an immediate grasp of all the keys mapping organization. In a few words i find this page really unfriendly at best and i'd rather vote to have back the old tree view.
*** Bug 42041 has been marked as a duplicate of this bug. ***
*** Bug 43928 has been marked as a duplicate of this bug. ***
I feel that the tree layout is better as well. It matches the layout used by KDE and GNOME. Another alternative, used by both NetBeans and Microsoft Visual Studio, is a long list. In the case of Microsoft Visual Studio, they prefix a category to the name (so the list sorts well) and provide type-ahead searching. See "http://msdn.microsoft.com/library/default.asp?url=/library/en- us/vsintro7/html/vxurfkeyboardenvironmentoptionsdialogbox.asp" for a broad description of how Visual Studio works (no pictures :( )
you know, i think i liked the tree layout better as well, but i didn't like the complaints that the preference page was way too large because of it. (for what it's worth, this preference page has caused me a lot of grief :) one point worth mentioning here: bug 7845 'API needed in Combo class to specify # of items visible' (38368 as well) is definitely a contributor to this usability problem. i run eclipse primarily on the mac, and i don't mind the keys preference page because of the excellent combo/popup control on the mac. i find when i use my windows machine, bug 7845, with a hardcoded limit of 5 items, is truly annoying. according to some ancient ui guidlines i have around here somewhere (win 95 ui guidelines book, i think), typical combo drop down length should be between 5 and 12. i think if we could see 12 instead of the current 5, it would help somewhat. of course, none of this necessarily means anything. we will be fixing this bug the right way so that (most) everyone is happy, but by 3.0, not by M4..
additional usability comments from bug 44436 (Michael Van Meekeren): I find it very difficult to set key bindings in the Window > Preferences > Keys page. It took me three attempts to change Ctrl+F6 to just F6 when testing bug 37280. The difficulty is that it is difficult to differentiate between: - when you are viewing existing key bindings - when you are setting new key bindings - what button do you need to press to assign a new key and to which category or configuration does it apply. Perhaps a very simple wizard would help... i.e. a button, "Change a key binding" -what key? - when shoudl this key binding be valid? -there is/is not a previous value, do you want to overwrite? -OK
*** Bug 44436 has been marked as a duplicate of this bug. ***
*** Bug 44989 has been marked as a duplicate of this bug. ***
additional usability comments from bug 44989 (expunged): The arborescent view of the keys beside the tree of the preferences was a bit strange in the UI, but at least it permitted to jump from one action to another without opening one or two combos. What would be great would be to : - Keep the category combo over... - ...a list of the commands of the category, which would have two columns, e.g. Step Into Shift+F5 Step Over F6 Step Return F7 Step With Filters F5 (the second one would be the active key, or whatever, maybe with dots or 'more') So that at one glance and with 4 clicks and 4 key strokes anybody could setup the proper key bindings for stepping for example. Hope this helps
*** Bug 55674 has been marked as a duplicate of this bug. ***
From bug 31731, comment 25 and bug 31731, comment 26: >How can I find out using the Keys preference page which commands are available >in a given context, e.g. dialog? ------- Additional Comment #26 From Douglas Pollock 2004-03-23 14:06 ------- Dani: No, I don't believe so.
*** Bug 56772 has been marked as a duplicate of this bug. ***
IMHO the main usability problem (with the current UI, lessened but still present with the tree UI) is finding * the command to which to (re)map a key, particularly * finding the category of the desired command Use case: user wants to make a particular gesture (perhaps inherited from a previous version or other tool) cause a particular UI change. E.g. sometime prior to 3.0-M8 (on which I am now), C-S-w brought up a nice window showing all one's currently-open editors. In 3.0-M8, C-S-w CLOSES all one's currently-open editors: quite a change. So I sought to remap C-S-w by going to Windows>Preferences>Workbench>Keys at which I see UI like Active configuration Command Key Sequence When Despite the fact that the help for > Changing the key bindings > Keys still shows the old (and IMHO better) UI, I know how to map from category to command to key: choose the category, choose the command, remove old assignments (if desired), type the key sequence in the appropriate field, and assign it. But I have no idea how to go in the reverse direction: how can I find the command that brings (or brought--perhaps I'm screwed) up the window containing currently-open editors? (AFAICS--am I missing something?) There is no assistance provided for finding the name of the desired command, much less its category. Can the user lookup a command or its category without guessing or brute-force search? FWIW I also prefer the tree to the combos (and I don't give a damn how big the @#$%^&! page gets :-) just because it makes BFS easier, but I suspect a more usable alternative lurks ...
I'm using the 0422 build and the new keybinding page is not much different in function than the original. The only improvement is the search text field. But the user often has *no* idea what the command is called because it never appears in a menu. So how about accepting wildcards? What the user really needs is "show me the keybindings which are effective in this editor only". And then of course some of those commands are going to be inherited and changing them will affect other editor types, so somehow this should be indicated. But when they remap a keybinding, they should be prompted "do you want to change this only for the FOO editor, or for all editors which use this keybinding". Of course I am using the term editor incorrectly and it should be context or something. Also, it should be possible to navigate immediately to a command by invoking its keybinding. The "Key Sequence" Text control alreadly allows me to simply type the new keybinding. The mysteriously unlabeled search Text control could allow you to do the same for existing keybindings. Just type the keybinding and wham you're there. I would also recommend describing both this and the name-lookup behavior of this widget with a Label. You could proably get away with using a single Text control vs. 2 because most users no the names of BACKSPACE, UNDO, REDO, and DEL. For multi-stroke accelerators, you could use a drop-down to show the current partial matches.
Randy: Thanks for your comments, but the new keys preference page has been pulled -- starting with today's integration build. We don't have enough time to iron out the bugs in the new preference page.
That's very disappointing. What about adding the find-by-invoking Text Control to the old page? This would improve the usability of the old page by 200%, studies indicate ;-).
The (second) new page is being pulled partly because of that control. There are some peculiar usability and performance problems with it, and the person who wrote the code is not here right now. There are other problems with the page, and we just don't have enough time to have someone else go in and figure out the code and sort it out. If someone here wanted to devote the time to cleaning it up, we have a list of problems that need to be resolved.
Now I am confused. The control I am talking about does not exist on either the new (as of 0422) or old page.
*** Bug 63747 has been marked as a duplicate of this bug. ***
I have a suggestions for a new UI for customizing keybindings (surprise :-). Instead of basing the UI on the implementation (Config/Category/Scope), base it on the user's mental model. I believe that the user would like to see a choice of things that they work with (mostly editors), such as "Java Editor", "Synchronize View". (Alternatively, you could give the use *NO* choice, and they would edit whatever is currently active. Or if not, at least the currently active mode could be pre-selected) Once they have selected one of these, they could be shown the inheritance somehow, such as 'Java editing' inherits keystrokes from 'text editing'. Of course you would then show all of the actions available to this mode. There should be a filter to show only actions which have keybindings. With this filter active, what you end up with sounds a lot like the patch which was recently created to display available keybindings. So why not get more mileage from this UI and make it the mechanism for customizing keybindings too. All you need is the filter toggle, and a few buttons which walk the user through customization. Instead of a conflict table and a "When" Combo selector, give the user choices they understand like "Remap", "Assign", "Unassign", "Remap for the Java Editor only". Don't show the conflicts (assignments) until they matter. If I want to assign CTRL+RIGHT to "Navigate/Go Into", I don't care that it means "Next Word" when editing text.
Starting from 3.0 release, I find the Keys preferences page very confusing. I think the page is trying to do too many things. I think there should be a separate sub dialogs to show different aspects of key bindings: 1. To show to which keys a particular command (from a simple sorted list) is bound to in which context for current key configuration, platform, locale. The user should be able to show key bindings for additional key configurations, platforms and locales for comparing. 2. To show what commands are bound to a particular key sequence. The user should be able to simply type that key sequence. The user should be able to show key bindings for additional key configurations, platforms and locales for comparing. The main page should concentrate on assigning key sequence to a command (once- again selected using a simple sorted list of commands). Once the command is chosen only allowed key configurations, contexts, platforms and locales should be available. The conflicts should be shown with explaination.
Created attachment 14344 [details] Improved overview of KeyBindings An improved ui for showing an overview of keybindings.
Created attachment 14345 [details] Key Sequence based filtering Uses org.eclipse.ui.internal.keys.KeySequenceText.
Created attachment 14346 [details] Natural key based filtering. Uses org.eclipse.ui.internal.keys.KeySequenceText.
Created attachment 14347 [details] Command based filtering
Created attachment 14348 [details] The zip file containing the plugin. The plugin I have implemented for above attachments. The plugin works on 3.0 and 3.1. Feel free to integrate it into the product. [DISCLAIMER: The plugin is as is. No guaruntees]
That's a nice UI for searching through all keybindings globally. But I still stand by my comments from above: 1) The user should be able to see keybindings for the current "contexts" or any other. I don't see a reason to ever present all keybindings to the user. When you customize the keybindings in Microsoft Word, you aren't bombarded with the commands from Excel and Powerpoint. 2) The user should be able to make changes without learning an additional UI.
But, for example, look at the keyboard customization dialog for Microsoft Visual Studio. Also, you should try "Ctrl+Shift+L", if you haven't already.
Could this patch be modified to fit into the existing preference page? Could you explain a bit more about this plug-in (e.g., why the "X" on some contexts and not others, why only natural keys and not the full key binding, etc.)?
I guess the plugin is really meant to be invoked at anytime while working in the Eclipse IDE. It is somewhat analogous to the "multi key stroke assist" window. The "multi key stroke assist" window only appears when the user types part of the multi key stroke key sequence. The difference is that this plugin can be invoked at anytime to explore the keybindings for applicable context (s). The user is able to explore using either the key sequence, natural keys or command by simply typing the prefix in respective text boxes. Note that the popup window is context sensitive. It shows the most applicable key bindings in dark gray background. It shows the next most applicable key bindings in gray background. The keybindings that are not in the currently active contexts are shown in gray foreground. The [X] on some of the contexts is meant to show that that context is not currently active. It also helped with sorting the Contexts column so that non applicable rows are displayed at the end of the table. The [X] could be changed though. The panel at the bottom shows the active platform, configuration and contexts with their ordinal numbers. The natural key based exploration allows the user to see what variants of natural key + modifier are already taken and by inverse which are combinations are not taken so that more key bindings could be defined. It also helps to analyze the consistency of key binsingd i.e. the meaning of modifier. Does that make sense? [The plugin was inspired by the describe-key and where-is commands in Emacs] I am not a Eclipse developer so I do not know how to create a patch.
*** Bug 75075 has been marked as a duplicate of this bug. ***
Add category 'All' with all command names In the Keys Preference Dialog tab Modify add the command category 'ALL' that contains all command names. So the user has not to search through all categories to find a certain command name
"All" should probably also be the default selection
Having "All" be the default would be like having the open type dialog default to "*".
Taking all of Chris' [KeyBindings] bugs.
Just a few quick observations on key bindings UI from the v3.1 M3 driver. 1. I like the fact that users can now view all the key mappings (in one glance) 2. I am an advocate for DM (direct manipulation) for UI, so making the "view" tab read only is not a good thing for usability. I think there's opportunity to combine the current "view" and "modify" tab into one coherent whole, where users can get an overall view of their current key mappings, while having the ability to modify individual elements on the list. However, one key usability improvement would be to make sure that the "active configuration" (e.g. default, Emac...) drives the visible list. Currently, there's no clear mental model linkage for users who initially stare at the list in the "view" tab 3. I feel we are introducing a "visual language" for users to define their key bindings (for example, in the "modify" tab, (extends Default), (extends Editing Text) in the UI is totally strange to me). As a user, I have done enough coding in the source editor, now in the UI dialog box I need to think in terms of super class again? :-) 4. Minor point: if we provide an "export..." feature, would users be able to import their own mappings defined outside into the IDE (and give it a configuration name)?
I strongly agree and disagree with Jin's comments. The new table presentation and default filter of showing all commands is a disaster. It almost works for Eclipse by itself. But, doesn't scale and requires that the user guess at the category a command falls under (is it Text, or Source, or maybe Edit?? They're all the same thing, and wait until GEF adds Format to the list of categories). There needs to be "context" (in the user sense) selection such as Workbench, Java Editor, HTML Editor, PDE Editor, Synchronize View, etc. For the selected context, a tabletree should probably be available, but I'd like to be able to turn off the grouping by category. It doesn't help me when I already know the Action's name. I agree that this tab should be the only tab and should provide customizing.
Perhaps this isn't clear, but clicking on one of the columns will cause the list to be sorted by that column. So, for example, clicking on the context column would cause the list to be sorted by context.
*** Bug 80480 has been marked as a duplicate of this bug. ***
I noticed that, despite the strange >column< markings. So this is a workaround to filtering by context, but then I would want secondary sorting column. This column is taking up a lot of horizontal real estate to show what should be in a heading or combo box of some type. Another possibility, is that the keybinding preference page appear in multiple places with different root inputs. So under Java->Editor, there would be a Keybindings page or tab.
The Keys pref page should also allow to view all key bindings, currently it only shows the ones with an assigned key sequence. This is especially a problem for new users that look for a command which has no key binding yet. Finding it on the Modify page requires the user to search in the various categories.
There is a secondary (and a tertiary and a quaternary) sort column. However, to keep the UI simple, only the primary sort column is indicated. Clicking on the context column actually makes the sort order: context, categories, command, key sequence. How do people feel about removing categories entirely? Is this feasible?
I'm hoping to look at this again for 3.1.
*** Bug 89723 has been marked as a duplicate of this bug. ***
The preference page re-work has been pulled for the 3.1 plan to work on performance.
Is the keybinding table going to get pulled as well? It is rather misleading, since there are lots of commands which can have keybindings assigned, but they don't appear in that table because there is no current binding.
There is no further work planned for the keys preference page for 3.1.
*** Bug 96352 has been marked as a duplicate of this bug. ***
Moving Dougs bugs
New keys page in 3.3 PW
