Community
Participate
Working Groups
Build RC1 1. Workbench / Keys preference 2. Select "Save" command (N.B. active configuration is "Standard") Observe: There are 3 key sequences: Ctrl+S Command+S Ctrl+X Ctrl+S The first (Ctrl+S) appears in red and is listed as a "<conflict>". Global scope; Standard configuration. Selecting the first makes "<undefined> <conflict>" appear below. Expectation (1): "conflict" suggests badness, but I have no clue what the UI is trying to warn me about. It would be helpful if a brief explanation appeared when a conflict entry is selected. Expectation (2): Having a conflict on factory settings feels like there is something wrong with the product. Is there? Expectation (3): Does "<undefined> <conflict>" really make sense? Many other command have similar conflicts: Build All, Close, Close All (double conflict), Content Assist, Context Information, Copy, Cut, Delete Line, Delete to End of Line, Find and Replace, Find Next, Find Previous, Go To Line, Incremental Find, Incremental Find Reverse, Next, Next Editor, Next Perspective, Next View, Open Resource, Paste, Previous, Previous Editor, Previous Perspective, Previous View, Print, Redo, Save As, Scroll Line Up, Scroll Line Down, Select All, Show Ruler Context Menu, Show View Menu, Switch To Editor, Undo.
*** 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.
