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.
It is better to use Toolkit.getMenuShortcutKeyMask() instead of Event.CTRL_MASK for Menu Shortcuts, since not all platforms use CTRL_MASK for Menu Shortcut. For example Mac OS X uses Event.META_MASK. See this document for more details: [Section Swing Menus and Menu Items] http://developer.apple.com/technotes/tn/tn2042.html#Section1_3
From nbdev: - I suggested patching org.openide.util.Utilities.{add,read}Modifiers - Mike Jackson notes that Command-H is reserved and should not be mapped, i.e. do not map this to ReplaceAction
Sounds like Tim is working on this?
Yes, I have a patch, and no reason I know of this couldn't be done for 3.6. Changing to DEFECT - really, hardcoding CTRL-MASK for this sort of thing is a bug.
Created attachment 12730 [details] Diff using Toolkit.getMenuShortcutMask()
The attached patch is very simple - more or less a global search and replace, with a few exceptions. On Windows, no noticable problems; I even tried this with a patched Toolkit on Windows which returned SHIFT_MASK as the accelerator. Obviously typing was a little difficult, but all of the editor keys I tried worked with SHIFT. Tomas, you suggested on nbui that this wouldn't work for some reason or other. Could you explain that a little more clearly? So far I can't find anything broken - no reason not to commit it. The patches I tried on my Mac the other day were almost the same, and Command worked fine. Am I missing something?
Its not enough. The biggest problem is with ShortcutsFolder. There are module registered bindings for actions and the folder use ${m}-${key}, where m is the modifier state (C for control and so on) and the key is the name of the key. I won't be that bold and treat the "C" as a shortcut key mask, but you can try it on your new G4 toy. Possible problem: users won't be able to map real Ctrl? Now, there is a shortcuts editor (actually two of them, core and editor) which needs to type "Command" on OSX. The other problem are those small differencies in customs ofdifferent platforms, be it Cmd-H or any usual action (exit?) For the shortcuts folder, it may be simple: provide syntetic mask letter (say Q) and map it to current menu shortcut, then go update all the bindings in all the modules. For real OSX citizenship, we'll need profiles.
Check out my last post on the thread in nbui - we might be able to get 90% of the way there by remapping CTRL -> Command but checking a map for any keystrokes that cannot be remapped. An inverse function would be needed to be able to show real mappings in the UI (here some synthetic mapping might be better, I like that idea). Result: most things would be properly mapped on OS-X; it would be possible to do better things later...some method like: KeyStroke Utilities.remapKeyStroke (KeyStroke desired); If the caller binds the *output* of this method, remapping things like CTRL-H can also work. It's not as nice a solution as profiles, I'm just afraid profiles is more work than anybody will want to do, so we'll end up doing nothing (as we apparently have for a long time). I like the synthetic key mask approach better, but it means that modules will have to change their code, which makes it much less transparent. Either way it makes some troubles for docs - it would be very nice if the IDE could auto-generate a nice, formatted, *correct* list of all shortcuts, keystrokes, etc. and print that from the welcome screen - then no matter what, there would be some correct documentation of it.
Contempating the issue a little more...with auto remapping of available ctrl- combinations to command- we would still need a synthetic keymask for *user defined* (actually, two - one for the real ctrl key and one for the real command key) shortcuts, so these would properly be interpreted (in other words, when interpreting a keystroke, first check if there is one registered with a synthetic mask, in which case, process it with no remapping). Eventually provide a way for modules to register keystrokes using the synthetic masks if they want to ensure no reinterpretation. Does this sound workable, or am I making any logical mistakes here or missing anything? I'm trying to find a solution that is as non-disruptive to module writers as possible (so we don't require anyone to rewrite any code or have to create per- platform key mappings if they don't want to).
Well, it's pretty clear we're not going to solve this in time for 3.6 - if there's a 3.6.1, maybe we could do it there. Rescheduling for 4.0 for now.
Is there a chance to get the attached diff as a patch for 3.5.1 and/or 3.6? This issue *is* really annoying, as one always have to think before using shortcuts.
Sure, we will consider it.
FYI, I have a working prototype of proper key remapping on my laptop. I doubt we'll get it in for 3.6 (it changes how *every* key is processed throughtout the IDE, which makes it a bit dangerous to integrate with so little time for testing between now and the release). But if there's a 3.6.1, we ought to be able to do something for that. What it does: - Introduces a new class, util.KeyRemapper, which returns a per-platform default instance - It is called from the system-wide winsys key event dispatcher, to remap keystrokes before they are processed - Remapping can be suspended for controls that want explicit keys (really only the new keyboard short entry dialog needs this) - Remappings are compared - Against a Map of explicit remappings, in which case the explicit remapping is used (so you can completely swap one keystroke for another, i.e. F3 -> Command-G) - Against a list of OS-consumed keystrokes - if the remapping rule would transform a keystroke into something the OS wants, don't do the remapping (it stays CTRL-something) The OS-X implementation will swap Ctrl- for Command- except in cases where either of the above rules come into play. What works now: - CTRL- bindings are remapped to Command- except where they would conflict with Apple's list of system-consumed keystrokes. Switches are available to include in that list the keystrokes consumed on multi-locale installs of OS-X and laptops, which do some funny things with function keys - The keyboard shortcuts editor will display the bindings as the user would type them, so if a key is remapped to Command-, that's what the editor will show - Explicit rebinding of keystrokes, for example, Find Next -> Command-G, Goto -> Command-Shift-G What doesn't work: - Command keys added in the keyboard shortcuts dialog don't work right yet (the explicit keystroke mask is getting stripped out, simple to fix once I find who does that) General ToDos: - It makes it possible for modules to register explicit shortcuts (shortcuts that should not be remapped) by including a synthetic key mask in their definition (as text it is just specified by X - Utilities.addModifiers()/readModifiers() will now interpret this correctly). - (Nice to have) Currently the key remapping is hardcoded; it should be converted to per-platform Properties files or some XML format for defining remapping rules - Strip the X character from display of module-defined explicit keystrokes, since it's meaningless to the user, it just marks a keystroke that shouldn't be remapped ever
Reducing priority to P3. I do have a trial patch for this issue nearly working, so I'll put something here pretty soon (once my issues for 3.6 are fixed).
Created attachment 13315 [details] Patch which routes calls in ShortcutKeyAndMenuEventProcessor through KeyRemapper, does some stuff with the keyboard shortcuts editor. Mostly working.
I haven't gotten any further on it, but attached is the current state of things, so it's not just on my hard drive. Todo: - Storage of explicitly mapped keys - somebody's stripping our pseudo keymask - Test with editor macro recording stuff - probably will need some adjustment
*** Issue 33082 has been marked as a duplicate of this issue. ***
Created attachment 16582 [details] Less invasive patch compliments of Trung and me
I've attached a revised patch which Trung came up with and I modified to exclude key combinations that can't be remapped. While it won't cover cases such as registering keystrokes directly into component input maps, it solves 98% of the problem. If it works as well as it promises, we will probably integrate it for promo D.
Should use getOperatingSystem() == OS_MAC rather than System.getProperty("mrj.version") != null.
Created attachment 16586 [details] Revised patch
I think the revised patch takes care of the lurking problems. What's changed: It will now be possible to register a keyboard action with a filename such as "X-C-I". The X is a marker that the key is explicit - that is, it should not be remapped to command or anything else. What this accomplishes: - It is possible for modules to provide non-remapped bindings to CTRL, so CTRL is not lost as a key. Particularly this is useful for CTRL-G - to be mac-like, Command-G should be Find-Next, but if Command always remaps to CTRL, we can't keep it CTRL on the mac, as would be sensible. - The keybindings editor now works. User-entered keys are registered as "explicit" - their filenames have "X-" at the beginning. When the user deletes a keybinding, it will first check for the standard name, and if that fails, check for "X-"+name. So if the user enters Ctrl-] it won't end up getting remapped and showing up as Command-] Note that the "X-" must come first in the name to make the shortcuts editor happy. I don't think searching all possible permutations of the name makes much sense. I'd like to commit this ASAP (tomorrow?). Where, in your opinion, should the addition of "X-" be documented?
openide/api/doc/org/openide/actions/doc-files/api.html#keymap and of course openide/api/doc/changes/apichanges.xml
Should probably go thru apireviews.
Fixed as part of issue 46811
verified/closed