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