Make Quake mode work with a German keyboard layout #13936

@DarthJahus commented on GitHub (May 27, 2021):

Maybe the Terminal should detect which key is at that position (keycode) and assign it automatically. Actually, what it does is detect how the user would write ` with his current layout and then assigns the key(s).

On mine, it was Win+alt+shift+&.

I use a custom Dvorak layout.

Of course, after manually changing the binding for Quake mode under Terminal's settings (Actions section), it works without issue.

I have assigned like this: win+< (write it manually)

As you said, Quake uses the key under Esc. For me, it's that <, and now, I can invoke Quake mode with Win+<.

@DarthJahus commented on GitHub (May 27, 2021): Maybe the Terminal should detect which key is at that position (keycode) and assign it automatically. Actually, what it does is detect how the user would write \` with his current layout and then assigns the key(s). On mine, it was <kbd>Win</kbd>+<kbd>alt</kbd>+<kbd>shift</kbd>+<kbd>&</kbd>. I use a **custom Dvorak layout**. Of course, after manually changing the binding for Quake mode under Terminal's settings (Actions section), it works without issue. I have assigned like this: `win+<` (write it manually) ![image](https://user-images.githubusercontent.com/7353366/119864624-b613ce80-bf12-11eb-9e38-50644729e673.png) As you said, Quake uses the key under <kbd>Esc</kbd>. For me, it's that <kbd><</kbd>, and now, I can invoke Quake mode with <kbd>Win</kbd>+<kbd><</kbd>.

claunia commented

@zadjii-msft commented on GitHub (May 27, 2021):

Unfortunately, the terminal settings only allows us to set keys by character, or VKEY name (in some limited scenarios).

I guess ` is VK_OEM_3 on a US keyboard. I wonder - if we added support for oem_3 as a key name, and bound to that by default, what key that would be on a German keyboard.

@zadjii-msft commented on GitHub (May 27, 2021): Unfortunately, the terminal settings only allows us to set keys by character, or VKEY name (in some limited scenarios). I guess <kbd>\`</kbd> is `VK_OEM_3` on a US keyboard. I wonder - if we added support for `oem_3` as a key name, and bound to that by default, what key _that_ would be on a German keyboard.

claunia commented

@DarthJahus commented on GitHub (May 27, 2021):

I've noticed that on my layout, the terminal defaulted to Win+alt+shift+&. Which is how ` is written with the layout. Would be indeed interesting to bind with key code instead of key characters.

Maybe, in the long term, Windows should have a shortcut manager, where users would be able to see system-wide bindings. Apps would register there with some kind of API. Just an idea.

@DarthJahus commented on GitHub (May 27, 2021): I've noticed that on my layout, the terminal defaulted to <kbd>Win</kbd>+<kbd>alt</kbd>+<kbd>shift</kbd>+<kbd>&</kbd>. Which is how \` is written with the layout. Would be indeed interesting to bind with key code instead of key characters. Maybe, in the long term, Windows should have a shortcut manager, where users would be able to see system-wide bindings. Apps would register there with some kind of API. Just an idea.

claunia commented

@lhecker commented on GitHub (May 28, 2021):

@zadjii-msft noticed that the key below the Escape key apparently almost always maps to the scan code 29.
He also had the idea that we could add support for key bindings like vsc(<N>) which creates a key binding not by character but rather by (Virtual) Scan Code. Afterwards we could bind quake mode to Win+vsc(29) by default.

In my opinion that's a really good idea we could pursue.
If no one does it by then I'll likely take a stab at it in the future.

@lhecker commented on GitHub (May 28, 2021): @zadjii-msft noticed that the key below the Escape key apparently almost always maps to the scan code 29. He also had the idea that we could add support for key bindings like `vsc(<N>)` which creates a key binding not by character but rather by (**V**irtual) **S**can **C**ode. Afterwards we could bind quake mode to `Win+vsc(29)` by default. In my opinion that's a really good idea we could pursue. If no one does it by then I'll likely take a stab at it in the future.

claunia commented

@dag03tsc commented on GitHub (Jun 1, 2021):

With the Spanish QWERTY layout, Windows pre-claims the default win+` shortcut for the emojis pane, as well as the more common win+. shortcut. Is it somehow related to this?

Unfortunately, this prevents the usage of the Quake Mode feature OOTB, as it requires a shortcut remap, but it's no drama.

Anyway, I guess it'd impossible to find a suitable fit-for-all-layouts alternative and 'globalSummon' seems to be the best approach.

@dag03tsc commented on GitHub (Jun 1, 2021): With the Spanish QWERTY layout, Windows pre-claims the default `` win+` `` shortcut for the emojis pane, as well as the more common `win+.` shortcut. Is it somehow related to this? Unfortunately, this prevents the usage of the Quake Mode feature OOTB, as it requires a shortcut remap, but it's no drama. Anyway, I guess it'd impossible to find a suitable fit-for-all-layouts alternative and 'globalSummon' seems to be the best approach.

claunia commented

@tunger commented on GitHub (Jun 2, 2021):

I would love to use Umlaut-keys for action binding, specifically ctrl + ö to open the terminal (which is also the default key binding in e.g. VS Code). That's not possible at the moment.
The suggestion from @lhecker seems really good to allow that kind of binding.

@tunger commented on GitHub (Jun 2, 2021): I would love to use Umlaut-keys for action binding, specifically `ctrl + ö` to open the terminal (which is also the default key binding in e.g. VS Code). That's not possible at the moment. The suggestion from @lhecker seems really good to allow that kind of binding.

claunia commented

@vadimkantorov commented on GitHub (Jun 2, 2021):

Same question for US-International layout (that I use to avoid French AZERTY layout). And maybe other layouts that use backtick for typing accents

@vadimkantorov commented on GitHub (Jun 2, 2021): Same question for `US-International` layout (that I use to avoid French AZERTY layout). And maybe other layouts that use backtick for typing accents

claunia commented

@dag03tsc commented on GitHub (Jun 2, 2021):

I would love to use Umlaut-keys for action binding, specifically ctrl + ö to open the terminal (which is also the default key binding in e.g. VS Code). That's not possible at the moment.

Maybe Unicode could come in handy for that purpose.

With the Spanish QWERTY layout and win+\u00f1 as mapping, I can summon the action with the win+ñ actual keybinding indeed.

Try to use ctrl+\u00f6 as mapping. Does it work for you?
But I'd recommend you to change the VS Code keybinding before anything else, just to make sure it's free and WT can claim it right.

@dag03tsc commented on GitHub (Jun 2, 2021): > I would love to use Umlaut-keys for action binding, specifically `ctrl + ö` to open the terminal (which is also the default key binding in e.g. VS Code). That's not possible at the moment. Maybe Unicode could come in handy for that purpose. With the Spanish QWERTY layout and `win+\u00f1` as mapping, I can summon the action with the `win+ñ` actual keybinding indeed. Try to use `ctrl+\u00f6` as mapping. Does it work for you? But I'd recommend you to change the VS Code keybinding before anything else, just to make sure it's free and WT can claim it right.

claunia commented

@Raton-Laveur commented on GitHub (Jun 3, 2021):

French AZERTY layout

which actually has ² below the ESC key. Remapping the quakeMode action as "win+²" does not do anything.

@Raton-Laveur commented on GitHub (Jun 3, 2021): > French AZERTY layout which actually has ² below the ESC key. Remapping the quakeMode action as "win+²" does not do anything.

claunia commented

@dag03tsc commented on GitHub (Jun 6, 2021):

French AZERTY layout

which actually has ² below the ESC key. Remapping the quakeMode action as "win+²" does not do anything.

@Raton-Laveur, try to map it with Unicode as win+\u00b2.

You must write that inside thesettings.json file with any text editor; otherwise, it won't work, because the GUI editor forbids keybindings with backslash characters.

I've tested this approach with a bunch of weird chars and it seems to be working pretty good, so you may use any Unicode char.
Let us know if it works for you too.

@dag03tsc commented on GitHub (Jun 6, 2021): > > French AZERTY layout > > which actually has ² below the ESC key. Remapping the quakeMode action as "win+²" does not do anything. > > @Raton-Laveur, try to map it with Unicode as `win+\u00b2`. You must write that inside the`settings.json` file with any text editor; otherwise, it won't work, because the GUI editor forbids keybindings with backslash characters. I've tested this approach with a bunch of weird chars and it seems to be working pretty good, so you may use any Unicode char. Let us know if it works for you too.

claunia commented

@Raton-Laveur commented on GitHub (Jun 6, 2021):

@dag03tsc it works, thank you.

@Raton-Laveur commented on GitHub (Jun 6, 2021): @dag03tsc it works, thank you.

claunia commented

@dag03tsc commented on GitHub (Jun 7, 2021):

@Raton-Laveur, I'm glad to hear that! You're welcome!

There seems to be some kind of inconsistency with the GUI remapping method.

Some chars are parsed to its Unicode \uXXXX, while others don't, and I'm not really sure why, but I guess it could be charset-driven somehow.

Maybe it relays on the charset of the settings.json file, or it relays on the system's default charset instead.

As an example, with the Spanish QWERTY layout, win+ñ goes right inside the setting.json as is, but it should be listed as its win+\u00f1 Unicode reference instead. Otherwise, the action cannot be summoned.

Anyway, I guess this could be fixed just by parsing all chars with no discrimination at all but, of course, exclude special keycodes like +, win, numpad_*, f*, etc.

@dag03tsc commented on GitHub (Jun 7, 2021): @Raton-Laveur, I'm glad to hear that! You're welcome! There seems to be some kind of inconsistency with the GUI remapping method. Some chars are parsed to its Unicode `\uXXXX`, while others don't, and I'm not really sure why, but I guess it could be charset-driven somehow. Maybe it relays on the charset of the `settings.json` file, or it relays on the system's default charset instead. As an example, with the Spanish QWERTY layout, `win+ñ` goes right inside the `setting.json` as is, but it should be listed as its `win+\u00f1` Unicode reference instead. Otherwise, the action cannot be summoned. Anyway, I guess this could be fixed just by parsing all chars with no discrimination at all but, of course, exclude special keycodes like `+`, `win`, `numpad_*`, `f*`, etc.

claunia commented

@tunger commented on GitHub (Jun 7, 2021):

Try to use ctrl+\u00f6 as mapping. Does it work for you?

@dag03tsc thanks a lot, it works!
Would probably be worth mentioning in MSDN that this possibility exist: https://docs.microsoft.com/en-us/windows/terminal/customize-settings/actions#accepted-modifiers-and-keys

@tunger commented on GitHub (Jun 7, 2021): > Try to use `ctrl+\u00f6` as mapping. Does it work for you? @dag03tsc thanks a lot, it works! Would probably be worth mentioning in MSDN that this possibility exist: https://docs.microsoft.com/en-us/windows/terminal/customize-settings/actions#accepted-modifiers-and-keys

claunia commented

@vadimkantorov commented on GitHub (Jun 7, 2021):

Also, if this settings JSON flavor supports comments, maybe worth mentioning some instructions there directly inline

@vadimkantorov commented on GitHub (Jun 7, 2021): Also, if this settings JSON flavor supports comments, maybe worth mentioning some instructions there directly inline

claunia commented

@lhecker commented on GitHub (Jun 7, 2021):

I've installed the French locale and its AZERTY layout. A key binding for win+² works as expected for me.
Please make sure to save your settings.json file as UTF-8 and not as CP 1252 or something...

(cc @carlos-zamora)

But the way key bindings currently work, they might break if you switch between multiple keyboard layouts.
They're parsed only once during app start. If you switch to a different keyboard or language layout later on, the virtual keycodes will not match anymore and the keybinding will appear to be broken.

For instance: If you start Windows Terminal with a win+² key binding it'll be recognized as a shortcut for "windows key + VK_OEM_7" (VK_OEM_7, or 0xDE, is the virtual key code for ² on a French AZERTY keyboard).
If you then switch to an English keyboard - even if you keep the AZERTY layout! - the very same key will now be recognized as VK_OEM_3, or 0xC0, instead and the key binding will not work.
For quake mode this issue is amplified as we also only call RegisterHotKey once with the virtual key code determined during app start.

For this reason and many more we certainly need to listen for WM_INPUTLANGCHANGE in the future (also mentioned in https://github.com/microsoft/terminal/issues/8871).

@lhecker commented on GitHub (Jun 7, 2021): I've installed the French locale and its AZERTY layout. A key binding for `win+²` works as expected for me. Please make sure to save your settings.json file as UTF-8 and not as CP 1252 or something... --- (cc @carlos-zamora) But the way key bindings currently work, they might break if you switch between multiple keyboard layouts. They're parsed only once during app start. If you switch to a different keyboard or language layout later on, the virtual keycodes will not match anymore and the keybinding will appear to be broken. For instance: If you start Windows Terminal with a `win+²` key binding it'll be recognized as a shortcut for "windows key + VK_OEM_7" (`VK_OEM_7`, or 0xDE, is the virtual key code for ² on a French AZERTY keyboard). If you then switch to an English keyboard - **even if you keep the AZERTY layout!** - the very same key will now be recognized as `VK_OEM_3`, or 0xC0, instead and the key binding will not work. For quake mode this issue is amplified as we _also_ only call `RegisterHotKey` once with the virtual key code determined during app start. For this reason and many more we certainly need to listen for `WM_INPUTLANGCHANGE` in the future (also mentioned in https://github.com/microsoft/terminal/issues/8871).

claunia commented

@sbatten commented on GitHub (Aug 25, 2021):

I am using Colemak Mod DHk and am unable to bind backtick or the vk or sc code to quake mode. Switching to basic US Qwerty fixes the issue, but backtick is not special in my layout like German. Is there some checking going on that prevents my keybind that shouldn't be?

@sbatten commented on GitHub (Aug 25, 2021): I am using [Colemak Mod DHk](https://github.com/ColemakMods/mod-dh/tree/master/klc/Colemak-DHk) and am unable to bind backtick or the vk or sc code to quake mode. Switching to basic US Qwerty fixes the issue, but backtick is not special in my layout like German. Is there some checking going on that prevents my keybind that shouldn't be?

claunia commented

@lhecker commented on GitHub (Aug 25, 2021):

@sbatten I've installed the US ANSI Colemak-DHk and it works as intended in the Preview version of Windows Terminal (1.11.2362.0).
Are you on the same version? And if so: Do you use the same layout or a different one?

@lhecker commented on GitHub (Aug 25, 2021): @sbatten I've installed the [US ANSI Colemak-DHk](https://github.com/ColemakMods/mod-dh/blob/7503dd8b9dd1acc2a0580bfb40ded603c295e2b1/klc/Colemak-DHk/colemak_dhk_ansi_us.zip?raw=true) and it works as intended in the Preview version of Windows Terminal (1.11.2362.0). Are you on the same version? And if so: Do you use the same layout or a different one?

claunia commented

@sbatten commented on GitHub (Aug 26, 2021):

@lhecker I am using 1.10.1933.0 (Preview from the store on Win 11) and yes that is the same layout. My default seems to be:

Also, I also have keyboard layouts available, not sure if that matters. i.e. win+space toggles between layouts

@sbatten commented on GitHub (Aug 26, 2021): @lhecker I am using 1.10.1933.0 (Preview from the store on Win 11) and yes that is the same layout. My default seems to be: ![image](https://user-images.githubusercontent.com/6561887/130876266-67f0c0a7-9f8c-4282-8ce8-0b5a656a180d.png) Also, I also have keyboard layouts available, not sure if that matters. i.e. win+space toggles between layouts

claunia commented

@lhecker commented on GitHub (Aug 26, 2021):

@sbatten Oh in that case you'll have to wait until 1.11 unfortunately.
The required fixes that introduced vk() and sc() are only part of 1.11, which should be in (public) preview relatively soon.

@lhecker commented on GitHub (Aug 26, 2021): @sbatten Oh in that case you'll have to wait until 1.11 unfortunately. The required fixes that introduced `vk()` and `sc()` are only part of 1.11, which should be in (public) preview relatively soon.

claunia commented

@sbatten commented on GitHub (Aug 26, 2021):

ah thanks for the clarification

@sbatten commented on GitHub (Aug 26, 2021): ah thanks for the clarification

claunia commented