terminal Default bound key combinations are not working as expected on international keyboard layouts C++

Environment

Windows build number: Microsoft Windows [Version 10.0.19041.450]
Windows Terminal version (if applicable): 1.2.2381.0

  • Swedish keyboard layout

Steps to reproduce

invoke the Font Size Increase command ctrl+= on a Swedish keyboard layout.

(hint: that would be ctrl+shift+0)

Expected behaviour

Font size increases one step.

Actual behaviour

Nothing happens.

Reflections

  • The new Command Palette (that I am already a huge fan of, despite it's flaws) insists that Increase Font Size is bound to ctrl+shift+0 (bonus bug?)

  • Referring to the Modifier keys section in http://docs.microsoft.com/en-us/windows/terminal/customize-settings/key-bindings#key-binding-properties it appears that all the characters that are shift:ed on an American keyboard layout are invalid bindings. This theory is also widely supported by the fact that Windows Terminal binds ctrl+shift+numeral to newTab and ctrl+alt+numeral to switchToTab.

  • International keyboards often move the special characters around on the keyboard. (In the case with the Swedish keyboard layout, to fit in the three extra vowels in our 29 letter alphabet.)

  • It appears that the problem is how Terminal deals with characters that are bound to the numeric keys.

Asked Oct 09 '21 13:10
avatar pstaag
pstaag

5 Answer:

It appears there are at least two conflicting visions of what MS terminal should be. One camp seems to be about making it something new and fixing historical issues (accepting that all of the world don't use English keyboards for instance). The other is about supporting the historical features of VT100+ that are widely used in the Linux world still. These are unlikely to be reconciled with a single configuration. For instance the VT* keyboard has to have separate key handlings, regardless of the desires consistency or non-English keyboards. So it seems there needs to be a VT100/200/etc mode , Xterm , and maybe a "MSTerm (ugh?)" mode which is targeted for non-terminal emulated applications.

1
Answered Oct 02 '20 at 16:52
avatar  of MiHondo2020
MiHondo2020

@lhecker you might be interested in this one.

These are unlikely to be reconciled with a single configuration.

Yeah... you're definitely struck at the heart of the issue.

As an aside: sorry -- this fell out of our triage queue and we just found it again. I apologize!

1
Answered Jul 02 '21 at 17:05
avatar  of DHowett
DHowett

@lhecker remove the triage tag if you agree with the characterization and the milestone being set to 2.0, ok?

1
Answered Jul 02 '21 at 17:06
avatar  of DHowett
DHowett

@DHowett I believe setting it as a goal for v2.0 is a good idea and I'll gladly tackle it. This issue is "basically" a sister-issue of #10203 and both can be solved simultaneously.

We need to introduce sc(N) and vk(N) to our shortcut sequences, which respectively stand for specific scan codes and virtual keys that are to be bound to an action. For instance Win+sc(29) would always bind to the key below the escape key, as virtually every keyboard in the world assigns the scan code 29 to the key below the escape key. 🙂

Now instead of binding zoom in/out to Ctrl+= and Ctrl+-, we need to bind it to Ctrl+vk(187) and Ctrl+vk(189) respectively. This is because for instance = on an US keyboard has the exact same virtual key as + on almost all international keyboards. Of course this doesn't work for all keyboards, but it should work for a significant fraction of them as far as I'm aware.

1
Answered Jul 02 '21 at 20:38
avatar  of lhecker
lhecker

:tada:This issue was addressed in #10666, which has now been successfully released as Windows Terminal Preview v1.11.2421.0.:tada:

Handy links: * Release Notes * Store Download

1
Answered Aug 31 '21 at 17:13
avatar  of msftbot[bot]
msftbot[bot]