Community
Participate
Working Groups
The characters displayed in the KeySequenceText should be the real characters, rather than their shifted values -- when using shift. In other words, the natural key should be the key that would have been typed if shift had not been down at the time of the key stroke. STEPS TO REPRODUCE: 1.) Open KeysPreferenceDialog and focus on the KeySequenceText widget. 2.) Type "Ctrl+Shift+6". ACTUAL RESULTS: "Ctrl+Shift+^" is inserted. EXPECTED RESULTS: "Ctrl+Shift+6" is inserted.
Talk to SWT.
felipe: This is another piece of the shifting problem. Let me know if you have an conclusive thoughts about the feasibility of providing a way of translated shifted characters to their unshifted values.
This same problem happens on Windows. There is nothing we can do for M3. We need to wait Steve come back from vacation (next week) and talk to him about this problem. You guys need low-level keydowns event for doing this. Same as Bug38757.
I guess we're basically looking for more detail from the event. While I have no idea how you might approach something like this, the following would be usable (from our perspective). Provide the unshifted character in the key code, whenever the state mask includes a SHIFT; otherwise, use the key code normally. Examples: "Ctrl+Shift+7" (US keyboard) event.character = '&' event.keyCode = (int) '7' "Ctrl+Shift+7" (Swiss German keyboard) event.character = '/' event.keyCode = (int) '7' "Ctrl+Shift+/" (US keyboard) event.character = '?' event.keyCode = (int) '/' "Ctrl+Shift+F" (US keyboard) event.character = (char) 0x06 event.keyCode = (int) 'f' "Ctrl+F" (US keyboard) event.character = (char) 0x06 event.keyCode = 0x00 "Ctrl" (US keyboard) event.character = (char) 0x00 event.keyCode = 0x40000 "Ctrl+Shift" (US keyboard) event.character = (char) 0x00 event.keyCode = 0x20000
*** Bug 42042 has been marked as a duplicate of this bug. ***
When implementing the key lookup, we should look up both the shifted and unshifted values. For example, 'Ctrl+Shift+7' on a German keyboard should match both 'Ctrl+Shift+7', 'Ctrl+/' and 'Ctrl+Shift+/'. On a US keyboard, it should match 'Ctrl+Shift+7', 'Ctrl+&' and 'Ctrl+Shift+&'. This is to alleviate some of the need to provide many different locale-specific key bindings. This doesn't mean all keyboards will be able to access all key bindings -- locale-specific key bindings will still be necessary in some cases. In KeySequenceText on KeysPreferencePage, only 'Ctrl+Shift+7' would be available for binding directly. A "backdoor" is available in which the user can (using the mouse) paste any key sequence they want into the KeySequenceText. It's unclear why a user would want to use this, but it is available if they want it.
*** Bug 41908 has been marked as a duplicate of this bug. ***
Fixed > 20030922 The event.keyCode field now contains the unaffected character. If the user types Ctrl+Shift+'a', keyCode will be 'a' while character is 0x01 (CONTROL A). On German keyboard, Ctrl+Shift+'2' the keyCode will be '7' and the character '/'. On English, the keyCode will be '7' and character will be '&'. When the character is the result of an IME (Input Method Editor), then the value of keyCode is zero.
work still needs to be done by platform-ui.
Created attachment 6192 [details] Workbench, KeySupport Modifies KeySupport to provide three types of accelerators from one SWT event: unmodified character, all modifier keys Ctrl+Shift+2 modified character, no shift Ctrl+@ modified character, shift Ctrl+Shift+@ Modifies Workbench to test each one of these possibilities in the order given. This means that on a Swiss German keyboard, the "Ctrl+Shift+/" should work out of the box. Will cross-test on Windows XP.
Created attachment 6195 [details] KeySequenceText, KeySupport, Workbench Fixes an indiscrepancy with how control-escaped characters were dealt with. This still leaves "Ctrl+Enter" appearing as "Ctrl+J" on Windows XP. Steve says this was dealt with by fixing Bug 42225, but I've yet to confirm (need a new build to work from).
Note: there are still imperfections between the way our key filtering mechanism works, and the way the native operating system can handle things. Most notably, Windows (but not Linux) allows unshifted key strokes to match the shifted equivalents. For example, on a Swiss German keyboard, "Ctrl+7" would match "Ctrl+/". We don't handle this case. The changes look good on Linux-GTK. chris: review/apply.
Created attachment 6200 [details] KeySequenceText, KeySupport, Workbench (version 3) Fixes a problem on Windows XP with incomplete key strokes.
fixed (via 43613)
