[KBM] CapsLock as a modifier in Remap Shortcuts

[kuroikyu]

Dozens of us don't use Caps Lock at all during our normal workflow (dozens!), so it would be nice to be able to use it as an extra modifier when using the Remap Shortcuts functionality.
This is already a thing in macOS world thanks to tools like Karabiner Elements or BetterTouchTool that allow yout to turn Caps Lock into the "Hyper" modifier as it's commonly refered to. I'm sure there's something similar for Linux but I'm not that familiar with it.

In terms of implementation, I don't mind if Caps Lock is not recognised as a modifier straight away since maybe other people don't see it that way. I would be fine using Remap keyboard to map Caps Lock to this new virtual "Hyper" modifier so I can start using it for my Remap shortcuts.

Thanks for the tool by the way, I'm going to start moving most of my maps from AHK to the PowerToys!

[eric6356]

My AHK key mappings are not working in the PowerToys Run popup window, they used to be fine in the Window Walker.😢

[beorereleverion]

I also use this to change the layout. Accustomed to linux, took the idea from Mac

[arjunbalgovind]

@crutkas this is one of the highly requested features. In terms of implementation details I was thinking of something along these lines:
UI: On the landing page, a user has the option to use Caps as a modifier. This has two effects:

• Caps Lock will no longer work as before, it will behave as if it were orphaned. So you can't turn Caps Lock on/off. If the user was stuck in the Caps on state before orphaning it, it's up to them to disable the remapping and fix it manually.
• Caps Lock should be selectable as a modifier in the Remap key and shortcut window, and no longer considered as an action key,
  We have to fix it to be one of the two behaviors, either modifier or action key, can't have both.

Implementation in the backend (Pseudo-C++ code):
We can't use GetAsyncKeyState for checking if Caps Lock is pressed, since we have to suppress Caps Lock events to prevent the oridinary behavior. Instead we have to workaround this by having our own bool variable which updates CapsLock state on receiving Caps key events. This is equivalent to storing our own keyboard state variable rather than using GetAsyncKeyState.

// Assume a bool variable is present in KBM state or some class like that which stores the state of Caps Lock.
// Assume Caps+A is remapped to Ctrl+V
Remap_method()
{
    // Suppress all caps lock events and update state
    if (CapsLockModifierBehavior && current key=CapsLock)
    {
       UpdateCapsLockBoolState(currentKeyEvent->keyUpOrDown);
       return 1;(suppress)
    }

    if (currentKey = A)
    {
         if (CapsLockState is pressed)
         {
             // Remap to Ctrl+V (same as existing logic). Wherever we reset back to the pressed modifiers, we can still sendInput CapsLock, but it should get read by the `UpdateCapsLockBoolState` method.
         }
    }

}

Possible quirks:

• Since we aren't using GetAsyncKeyState quirks can occur if a user switches between elevated and unelevated windows. We can guarantee it would work correctly only if elevated. This was the same thing that occurred in the original PT Run and ColorPicker hook implementations as modifiers were recorded in bool variables rather than using GetAsyncKeyState.
• We should make sure this doesn't break Narrator support. Caps Lock is an important key for accessibility and Narrator. Narrator runs at a lower level so this might not be an issue, but should be double-checked. If not this could be marked as a "non-accessible" feature with appropriate warnings.

[Zeroto521]

Well, I have used Caplos. It's great in some ways.
But it still has some problems.