Bugzilla – Full Text Bug Listing
| Summary: | [KeyBindings] preference page: conflicts on standard key sequences | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jim des Rivieres <jeem> |
| Component: | UI | Assignee: | Paul Webster <pwebster> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Darin_Swanson, mahesh.shikarpuri, markus.kell.r, Tod_Creasey |
| Version: | 2.1 | ||
| Target Milestone: | 3.3 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 176235 | ||
| Bug Blocks: | |||
|
Description
Jim des Rivieres
*** Bug 32586 has been marked as a duplicate of this bug. *** *** Bug 32673 has been marked as a duplicate of this bug. *** *** Bug 36328 has been marked as a duplicate of this bug. *** Per Darin's comments, I removed XMEN plugin and the old Antview plugin and I am able to use Content Assist without any conflict for version 2.1 Thanks Darin, MS fixed. you should not see conflicts anymore as of m3. Can you please explain Chris? If I don't see them how can I resolve when conflicts occur? Thanks. i'm going to reopen this. right now the keys preference page cancels out key bindings that directly conflict. i thought about it tonight and expect to put some conflict notification back in, including this time, a more descriptive way to handle these. (report the names of the two plugins trying to take the same key binding, for instance). ps. when jim first logged this bug, it was due to a much bigger problem. key bindings in parent/child configurations reported conflicting with one another when one was simply overriding another. that problem was very temporary. In 3.0, conflicting keybindings (same keySequence & same contextId) leads to the following unfortunate behavior: (a) The shortcut does not work for either command. There should be a defined sequence for trying all of the conflicting handler submissions (e.g. depth-first traversal in the plugin-dependencies tree). When a handler submission has set the "handled" attribute to false, the next handler should be tried, etc., until a handler has handled the shortcut. (b) When selecting the conflicting commands, their 'Assignments' list is empty. It should at least show the key bindings (and better yet: warn of a conflict). (c) Typing the keybinding in the Keys pref page yields a single disabled entry with red X icon and command name "Unassigned". No clue that there is a conflict. Conflicting commands are not mentioned anywhere. I filed bug 69279 for (a) of comment 8, since that's a command handling issue and not a problem with the preference page. Taking all of Chris' [KeyBindings] bugs. The preference page re-work has been pulled for the 3.1 plan to work on performance. Moving Dougs bugs Is this still a problem in 3.3? PW Still a problem in I20060926-0935. After adding a plug-in with the contributions below, choosing the keys preference page does not indicate a conflict when I choose File > Close. Only when I select Ctrl+W, the key sequence assignments table shows two bindings for the same sequence -- still with no conflict icon.
When I select zzClose in the list, the selection immediately jumps to the Close command. I cannot remove the second binding for Ctrl+W.
<extension point="org.eclipse.ui.bindings">
<key
commandId="zzPlugin.zzclose"
sequence="M1+W"
schemeId="org.eclipse.ui.defaultAcceleratorConfiguration" />
</extension>
<extension
point="org.eclipse.ui.commands">
<command
categoryId="org.eclipse.ui.category.file"
description="zzClose"
id="zzPlugin.zzclose"
name="zzClose"/>
</extension>
Make sure key conflict information is displayed in the new keys preference page. PW Conflicts are addressed in the new page: 1) the conflicting bindings are marked (in 3.3 with a '*') 2) trying to execute that binding will open the key assist dialog and let the user select PW new key preference page work. PW Verified in I20070615-1200. |