Cleans up key handling in drivers (was "fixes VkeyPacketSimulator is broken")

[BDisp]

Fixes a lot of keyboard related things, but does NOT fix #3054

Pull Request checklist:

• [c] I've named my PR in the form of "Fixes #issue. Terse description."
• [c] My code follows the style guidelines of Terminal.Gui - if you use Visual Studio, hit CTRL-K-D to automatically reformat your files before committing.
• My code follows the Terminal.Gui library design guidelines
• I ran dotnet test before commit
• I have made corresponding changes to the API documentation (using /// style comments)
• My changes generate no new warnings
• I have checked my code and corrected any poor grammar or misspellings
• I conducted basic QA to assure all features are working

[BDisp]

@tig have you at least looked at this PR to understand the reason for the changes?

[tig]

No, I've not had a chance. But I will asap.

[tig]

What is the setup required to actually get the VK_PACKET stuff
to come into play?

Is it an Telnet/ssh thing. ?

[BDisp]

What is the setup required to actually get the VK_PACKET stuff to come into play?

Is it an Telnet/ssh thing. ?

Yes, know it's used with RDP (Remote Desktop Protocol) where the unicode char is encoded with the virtual key.

[BDisp]

Typing in the first TextView mirrors all on the second TextView on the VK Packet Simulator. All the key bindings that aren't supported by the TextView will open the MessageBox with the the typed key binding information.

[tig]

What is the setup required to actually get the VK_PACKET stuff to come into play?
Is it an Telnet/ssh thing. ?

Yes, know it's used with RDP (Remote Desktop Protocol) where the unicode char is encoded with the virtual key.

I understand what the simulator is supposed to do.

I want to be able to use VK Packet support "for real". Do you know what I need to do in order to do that?

[BDisp]

What is the setup required to actually get the VK_PACKET stuff to come into play?
Is it an Telnet/ssh thing. ?

Yes, know it's used with RDP (Remote Desktop Protocol) where the unicode char is encoded with the virtual key.

I understand what the simulator is supposed to do.

I want to be able to use VK Packet support "for real". Do you know what I need to do in order to do that?

I never try it with a real support but here (#2008 (comment)) is a way to try it.

[tig]

@BDisp, you wrote this:

You are not wrong in saying "'â' is the lower case of 'Â`". However, in all of my testing, on the US ENG, DEU, POR, and other keyboards this is NOT how keyboards work, or what users expect.

For example, in either Windows Terminal settings, use the settings UI to change the keybinding for "New tab, proifle index 0"

Using the DEU keyboard, the "CTRL+SHIFT+ä" key (which in ENG is "CTRL+SHIFT+'" gets displayed as "Ctrl+Shift+ä" NOT "Ctrl-Shift+Ä"

The same is true for, eg.., the Key.D7.

[BDisp]

@BDisp, you wrote this:

You are not wrong in saying "'â' is the lower case of 'Â`". However, in all of my testing, on the US ENG, DEU, POR, and other keyboards this is NOT how keyboards work, or what users expect.

For example, in either Windows Terminal settings, use the settings UI to change the keybinding for "New tab, proifle index 0"

Using the DEU keyboard, the "CTRL+SHIFT+ä" key (which in ENG is "CTRL+SHIFT+'" gets displayed as "Ctrl+Shift+ä" NOT "Ctrl-Shift+Ä"

The same is true for, eg.., the Key.D7.

@tig I have a Portuguese keyboard and I know what I'm talking about. To get the â I need type shift+^+A but the shift modifier doesn't matter because it's only to get the ^. After type the A the result is â (remember that the A without shift represent the lower a).

To get the Â I need to type shift+^+shift+A , but the shift modifier doesn't matter because it's only to get the ^ but the second shift modifier to get the upper case A matter. After type A the result is Â.

Using a virtual keyboard isn't the same as a real keyboard. So a Ctrl+Shift+â is never possible because other modifier is been used, the Ctrl key. Only is possible Ctrl+Shift+A.
If I type Ctrl+Shift+/ I get the follow on WindowsDriver and it must represented as KeyCode.CtrlMask | KeyCode.ShiftMask | KeyCode.D7 because other modifier is been used, the Ctrl.

If I type Shift+/ I get the follow and we could consider as KeyCode.ShiftMask | (KeyCode)'/'

[BDisp]

My keyboard has more or less this layout:

Pressing Ctrl+Shift+~ in WT the result is ctrl+shift+~. Although I have the shift key pressed it's ignored if another modifier key, like the Ctrl or Alt, are also pressed. So only the lower character is considered (~).

Pressing Shift+~ in WT the result is shift+~. WT only consider the lower character (~) which isn't the right binding.

If I press Shift+~ in the Windows notepad I get nothing and only when I press Shift+~ again I get two ^^. This is normally for accented characters because the terminal is waiting for the next key pressed to write the right one. If I press Shift+~ and release and then press a I get â. If I press Shift+~ and release and then press Shift+a I get Â. This last normally we don't need to release the keys and is done at once, like Shift+~+a or Shift+~ and without release the shift press a.

Pressing Ctrl+Shift+7 in WT the result is ctrl+shift+7. Although I have the shift key pressed it's ignored if another modifier key, like the Ctrl or Alt, are also pressed. So only the lower character is considered (7).

Pressing Shift+7 in WT the result is shift+7. WT only consider the lower character (7) which isn't the right binding.

If I press Shift+7 in the Windows notepad I get /. This is right behavior. So, don't rely on the WT to test the right key bindings because we need keys that interpret the right writings as well. It's better to use the notepad to test the printable keys.

[tig]

@BDisp please read this: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-mapvirtualkeya

Esp:

This is the mode I believe Terminal.Gui should operate in.

The current code in this PR (and v2_develop) is broken w.r.t. keys like OemPlus and more. Neither of you nor I had this correct.

The _scanCodes HashSet is very broken (and has been since it was introduced). As an example:

This can be demonstrated in v1 (develop) using the ENG keyboard and trying to type @ (which is Shift-D2):

Since you use POR, you do not see this because you coded all this to assume POR. With the POR keyboard:

Likewise, ConsoleKeyMappingTests.GetConsoleKeyInfoFromKeyCode_Tests is (and has always been) broken:

This is broken too:

In short, your understanding of how VK_PACKET works is incorrect. Previously, I was confused too (in a different way).

I am currently working on this and will submit a PR to PR with my suggested changes in the next few days. Please work on something else in the meantime so we are not working against each other.

[BDisp]

This is bad in my opinion. Currently KeyCode.Delete=127 which represent the ASCII 127 (DEL) and the KeyCode.DeleteChar is a masked value that really represent the ConsoleKey.Delete=46, which represent the ASCII . and thus must be a masked value. In my opinion we should remove the KeyCode.Delete and replace the KeyCode.DeleteChar with the KeyCode.Delete, because we don't need the ASCII 127 represented as KeyCode, I think.
And the KeyCode.InsertChar should be replaced with KeyCode.Insert because ConsoleKey.Insert=45, which represent the ASCII - and we only must use the masked value for KeyCode.Insert. Do you agree?

[dodexahedron]

I think @BDisp is encountering what I was ultimately getting at but not communicating properly. 😅

Isn't globalization fun?

[tig]

@BDisp do you know what this is?

[BDisp]

@BDisp do you know what this is?

I think I used that a long time ago to use on the Application class to get some request, like the terminal type, but it mustn't work like that. Can be removed.