Windows 10 Remaps do not work under RDP

[rbreaves]

Describe the bug Autohotkey and sharpkeys are unable to remap modifiers successfully and consistently over RDP. (aka on the destination remote computer) I have no interest in trying to get remaps to occur on the local computer or device and to carry over to the remote machine. It has to be running on the destination to pick up on what app is in use.

Expected behavior Normal kinto remaps.

It appears like remapping via Microsoft PowerToys may be the only option. Previously PowerToys had its limitations, and may not be able to remap Alt-Tab, but given no remapping at all or lacking some remaps Powertoys may be something worth integrating in a future update for RDP specifically. In every other case though Autohotkey is the superior option.

[rbreaves]

Seems the remapping of Alt-Tab works in the version of 0.25 of PowerToys and app specific keybinds is an option, although possibly not for UWP apps as it only accepts programs exe names.

The settings are contained here "C:\Users\{username}\AppData\Local\Microsoft\PowerToys\Keyboard Manager\default.json"

A combination of autohotkey and Powertoys may actually make the reliable remapping of UWP apps under RDP possible.

[rbreaves]

The more I think about this problem the more I think a Kinto Agent running on the remote computer would be a better route to go. The agent would relay the active program running back to your host computer and your remaps could then continue to run normally as it would on your local. This would entail a little bit of a rewrite so that the active programs would be converted out to a file or something similar that will be monitored for changes.

The Powertoys key remapper while solid for some things also leaves a lot to be desired and would likely only work with several hackish things going on or some serious dev work by me whereas AHK is mature today - just needs an agent on the remote machine to grab a small amount of information to relay, the actively focused program, a small rewrite on the Kinto host and that is it.

[rbreaves]

This issue might be more complicated than originally thought Windows RDP to Windows RDP appears to work fine as long as the host is the only one running Kinto. The following work arounds are also useful.

; Switch Virtual Desktops
    ^WheelLeft::
        if (!last || A_TickCount-last > 500) {
            last:= A_TickCount
            Send {Ctrl down}{LWin down}{Left}{Ctrl up}{LWin up}
        }
    return

    ^WheelRight::
        if (!last || A_TickCount-last > 500) {
            last:= A_TickCount
            Send {Ctrl down}{LWin down}{Right}{Ctrl up}{LWin up}
        }
    return

[rbreaves]

Need to update this chain with the latest info - the issue is due to how the Win key is handled, some RDP clients to not appear to transmit it as well as others, currently on RDP clients on Windows appears to handle it well.

One way to possibly get around this is to drop the Win key mapping altogether in favor of having "Left Ctrl" in the normal position while also having "Right Ctrl" in the cmd key position. This might allow for resolving issues with RDP assuming it transmits the Right Control key properly and Kinto would then be able to run on both the Host and the Client at the same time.

Re-implementing the Win key may be desirable in some cases, but honestly not sure which ones and will need to be sussed out based on what can already be re-attributed to a mac-style hotkey.

This approach would also resolve this ticket as well. #376