Community
Participate
Working Groups
I20091006-0800 The org.eclipse.ui.bindings extension point should allow to target <key> elements to an input context. Currently, you can only target them to a 'locale', which is probably often a good approximation, but it's pain for users of an English OS but with an international keyboard layout. The current 'locale' attribute is fed by the system locale, which tells in what language UI text should appear. But for key bindings, an 'inputContext' or 'inputMethod' attribute would be more appropriate. This should be fed by the current keyboard layout, which is available from java.awt.im.InputContext.getInstance().getLocale(). I'm not sure it it's OK for us to use java.awt.im.InputContext. If not, we need equivalent API from SWT.
One example of this problem is that many non-English Mac users don't find the key binding for Navigate > Back. The one shown in the menu (Command+[) is not reachable on most non-English keyboards, since '[' is Option+5 and Command+Option+5 does not work. That's why we also have Command+Option+Left, but that's not shown in the menu. Similar stories exist around Command+/ for Source > Toggle Comment, etc.
(In reply to comment #1) > One example of this problem is that many non-English Mac users don't find the > key binding for Navigate > Back. The one shown in the menu (Command+[) is not > reachable on most non-English keyboards, since '[' is Option+5 and > Command+Option+5 does not work. That's why we also have Command+Option+Left, > but that's not shown in the menu. > Similar stories exist around Command+/ for Source > Toggle Comment, etc. Exactly what keyboard do they have ? Do you have bugs for the problems above ? I'm bit confused, in this example it is a non-english mac user. So in this case 'locale' + 'platform' should have worked. --- I'm not sure why you need to know the current keyboad layout as the value of the keycode during key events is not affect by the the keyboard layout. Also note that keyboard layout/input method can change dynamically and some system allow different windows (even controls) to have different states for the input method. Do you want to reassign all the keybinding every time the keyboard layout changes ?
Okay, I did some more testing and I think I understand your problem. I think what you need is: Bug 62431 Using 'addLanguageListener()' you receive a event everytime the input method changes and adjust the keybinding accordingly. Is that what you need ?
> I think what you need is: Bug 62431 Yes, that looks promising if there's a way to translate the keyboard language into a java.util.Locale. For the 'Navigate > Back' example, we could then keep COMMAND+ALT+ARROW_LEFT for all keyboard layouts on the Mac, but COMMAND+[ only for 'en'. That would solve bug 150087. Likewise, M1+7 for 'Source > Toggle Comment' only makes sense for 'de'.
(In reply to comment #4) > > I think what you need is: Bug 62431 > Yes, that looks promising if there's a way to translate the keyboard language > into a java.util.Locale. Not sure if locale is enough. See English US versus English International for example. Any given language can have any number of input. On Windows, speech and handwriting recognition are also consider input methods.
Do you really want the keybindings to dynamically disappear when you temporarily change input locales? I can only imagine how much this might slow down caret navigation in a document containing bidi/mixed-language content! Maybe an alternative is to say that the values of the SHIFT/OPTION modifiers are unknown/"don't care"? So, Navigate>Back == Command-(Option)-"[". If the User has to press Option to type the character "[", fine. For reference, Apple's own KeyNote displays "Font>Bigger" as "Command-+", not "Command-Shift-+". Text>Align Right is "Command-}", not "Command-Shift-}". That the user had to use the Shift key to type the character is considered non-essential. (SHIFT is considered interesting when the key is one of the characters A-Z) When the keybinding service receives an event for C-O-"[" on a German keyboard on the Mac, it could first check for a perfect match. If it doesn't find any matches, it could then strip off the unessential modifiers like Option/Shift to see if it then finds any matches. (You could instead register all the permutations, but that seems messy). If the application has defined both Command-"[" and Command-Option-"[", then it did something bad. Similarly, when displaying the keybinding String, the keybinding service would omit these "don't care" modifiers.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
