| Summary: | [KeyBindings] preference page: not intuitive | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Martin Aeschlimann <martinae> |
| Component: | UI | Assignee: | Paul Webster <pwebster> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bokowski |
| Version: | 3.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 176235 | ||
| Bug Blocks: | |||
Moving Dougs bugs Is this still a problem in 3.3? PW What a question. Yes, of course. The keys preference page is, IMO, one of the biggest annoyances in Eclipse! We need a way to quickly see all assigned and non assigned keys, all assigned and non assigned commands. Sorry, this is a multi-person left graveyard cleanup. Is this a problem in the experimental keys page? PW The experimental page also lacks the possibility to sort for shortcuts and to find out which keys are not yet taken. I noticed that ... that'll be fixed for 3.3 PW Providing the tree hierarchy is an open bug. PW *** This bug has been marked as a duplicate of bug 185517 *** |
20050920 Here are some issues that I have with the Keys preference page. I know that a new version is in work, but I better comment on the old page, hoping my comment can help on the new one: - The separation of the two pages using tabs isn't really natural. A double click in one page changes to the other. But no backlinking exists to see an entry in the table when editing a certain key on modify page. -> It seems to me that the modify page should be child (= popup) of the first one: I would solve this by only showing the table, no tab. Clicking on an entry lets you edit/remove the selected entry. To enter new entries (commands that have no short cut yet), you would need an 'Add' button to get the new dialog. Or, another alternative is to have the table show also the commands that have no assignments, but having a (not assigned) entry in the 'key sequence' column. - If I understand right, contexts ('When') in fact form a hierarchy. So when you want to know what keys you can use in the Java debug window, you have to look through the context hierarchy, from most specialized to general' to know what keys are assigned to what. It would be good to show this hierachy in a tree, I suggest on top of the table. Selecting a node would have the table below hide the keys that don't apply for the current context (keys that are hidden by more specific settings or that are in a completly different context) + In Dialogs and Windows + In Dialogs + In Windows + Editing Text + Editing Java Source ... - I like the way you can sort the table by clicking on the columns. Maybe additionally a find feature that searches over all the columns would be good.