This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When using shortcuts the keyboard layout is not german, i.e. when I press "cmd+minus" a "cmd+slash" is interpreted, tested in search shortcuts, config section. Entering text in a file etc. works fine, so mac os layout is right. How to change ? Is it a bug. Product Version = NetBeans IDE 7.2 (Build 201207301726) Operating System = Mac OS X version 10.7.4 running on x86_64 Java; VM; Vendor = 1.6.0_33 Runtime = Java HotSpot(TM) 64-Bit Server VM 20.8-b03-424
I can second this with NB 7.3 Beta2. Product Version: NetBeans IDE 7.3 Beta 2 (Build 201211062253) Updates: NetBeans IDE is updated to version , NetBeans 7.3 Beta 2 Java: 1.6.0_37; Java HotSpot(TM) 64-Bit Server VM 20.12-b01-434 Runtime: Java(TM) SE Runtime Environment 1.6.0_37-b06-434-11M3909 System: Mac OS X version 10.8.2 running on x86_64; MacRoman; de_DE (nb)
This is expected. AFAICT this is how it should behave. The keystroke is constructed from the code of the key that was pressed (not typed) and any modifiers. For example (sorry for having Greek layout and not German): In the Greek layout if you press letter 'Q' it produces the char ';' when catching the keyPressed event in both cases we have keyCode=81 but they produce completely different char. The shortcut set could be for example Ctrl+Q meaning that in order to access it you need to press Ctrl and the key with code 81 witch is 'Q'. The fact that in the editor it is translated to ';' in Greek layout should have IMHO no impact for the shortcut.
Sorry, but this would be completely different to every other application I have ever worked with before. When the menu states Ctrl+q or Cmd+q for quitting of course a user (and even developers are users of Netbeans) expect she has to press the Cmd or Ctrl key and additionally the key with q printed on it (of course in accordance to her keyboard layout).
Any comment on how this situation should be resolved? Thank you
As stated in the original description: - Netbeans has no problem to get this right in the editor-window, Alt+l (small L) is interpreted as @, Alt + 8 is interpreted as { etc. The key lettered z on my german (corresponding to the position of y on the english one) gives me a z. - When I go to "Collapse Fold" in Preferences/Options/Keymap and press Cmd+- on my keyboard, Netbeans warns me that this is interpreted as Cmd+/ and that this shortcut is normally used for "Toggle Comment". However when I overwrite this nonetheless I am able to use Cmd+- for "Collapse Fold", only the menu states (incorrectly) "Cmd+/" as the short cut.
Svata, any comments on how this should work? Thank you
Not MacOS specific, I can see CTRL-SLASH on Linux too, when pressing CTRL-SLASH, while editor types '-' when slash is pressed. Surprisingly CTRL + '-' (american slash = german minus) is interpreted as collapse block by editor, traditionally assigned to CTRL-MINUS. I am puzzled.
Oddly enough, JDK's KeyStroke.getKeyStroke() returns CTRL+SLASH and even low-level KeyStroke.getAWTKeyStroke(event) creates the same object. We would have to use KeyStroke.getKeyStroke(char, mods) to get the correct KeyStroke.
So, there's a new method in JDK 1.7, getExtendedKeyCode(), which should be used in preference to getKeyCode(). getExtendedKeyCode() gets the keycode translated through keyboard layout, while getKeyCode() gets the raw keycode. So I'll probably fix the Options/Keymap with an ugly hack, since we still need to run on JDK 1.6, where the method does not exist at all. In JDK 1.6, even Editor will probably not recognize CTRL+MINUS as collapse, bcs it will get CTRL+SLASH.
The following classes should (could) be fixed in addition to keymaps module: org.apache.tools.ant.module.wizards.shortcut.SelectKeyboardShortcutPanel org.netbeans.modules.form.editors.KeyStrokeEditor
Changeset: 8af82a4710e4 Author: Svata Dedic <sdedic@netbeans.org> Date: 2012-11-16 08:22 Message: Added JDK-specific KeyStroke creation
Yet another class: org.netbeans.modules.apisupport.project.ui.wizard.action.ShortcutEnterPanel When fixed in apisupport, please reassign to owners of the other classes mentioned in above comments. See the mentioned changeset for fix implementation details.
Changeset: b6ff35d98bdc Author: Svata Dedic <sdedic@netbeans.org> Date: 2012-11-16 09:47 Message: ant: Fixed national keyboard key names
Changeset: 1159aaa152b8 Author: Svata Dedic <sdedic@netbeans.org> Date: 2012-11-16 10:07 Message: form: Fixed national keyboard key names
Do I read this correctly, that the fix should be part of 7.3 final?
yes, it should be.
Integrated into 'main-golden', will be available in build *201211170002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/8af82a4710e4 User: Svata Dedic <sdedic@netbeans.org> Log: Issue #217279 - Shortscuts not in german keyboard layout: fixed Added JDK-specific KeyStroke creation
Integrated into 'main-golden', will be available in build *201211180002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/b6ff35d98bdc User: Svata Dedic <sdedic@netbeans.org> Log: Issue #217279 - Shortscuts not in german keyboard layout: fixed ant: Fixed national keyboard key names
Sorry, but now I tried NetBeans IDE Dev (Build 201301220001) and still see this issue with JDK 1.6.0_37; Java HotSpot(TM) 64-Bit Server VM 20.12-b01-434 as well as Java(TM) SE Runtime Environment (build 1.7.0_11-b21). In the Keymap editor window I chose "Netbeans" Layout and neither with Java6 nor 7 CMD+- does work. When I run NB with Java7, the shortcuts suddenly switch from using CMD to META in the display. When I force a combination by pressing CMD+- in JDK7 it states a conflict with another key and this is shown as CMD+/ as before. System: Mac OS X version 10.8.2 running on x86_64; MacRoman; de_DE (nb)
not a HR fix candidate, moving to next release.
Merging with issue #227247; the national keyboards are larger issue that it seemed at first. The original analysis was not complete enough. *** This bug has been marked as a duplicate of bug 227247 ***