Why keyboard shortcuts don't work on non-US layouts and how devs could fix it(tkainrad.dev)
tkainrad.dev
Why keyboard shortcuts don't work on non-US layouts and how devs could fix it
https://tkainrad.dev/posts/why-keyboard-shortcuts-dont-work-on-non-us-keyboard-layouts-and-how-to-fix-it/
211 comments
> Windows for backwards compatibility reports 'right-alt' as 'alt+control'.
Interesting because on French AZERTY we also have an "altgr" key, and while Windows considers alt-control equivalent (ie. you cant type alt-control-à as well as altgr-à to get an @), typing altgr itself never triggers ctrl or alt shortcuts, it only goes the other way.
Interesting because on French AZERTY we also have an "altgr" key, and while Windows considers alt-control equivalent (ie. you cant type alt-control-à as well as altgr-à to get an @), typing altgr itself never triggers ctrl or alt shortcuts, it only goes the other way.
Same with an Irish layout (which is QWERTY): AltGr+(aeiou) gets you áéíóú, but never triggers Ctrl+Alt.
This is actually fascinating to me. I’ve dealt with keyboard input numerous times (not WinForms or browser either) and I always devised a way where control characters were a bitwise with the keycode. You would have to include this in any input mapping. I can totally see where this key combo issue would be a problem in a UI scenario in the browser or other shortcut-laden desktop app.
I remember ATI Catalyst Control Center (GPU settings panel) infamously binding Alt+Ctrl+C systemwide to launch itself.
So when you wanted to type 'ć' in any program in Windows, it would not work, and launch CCC instead.
Luckily the shortcuts were user-modifiable. So first thing to do on Windows after installing GPU drivers was to disable this hotkey.
So when you wanted to type 'ć' in any program in Windows, it would not work, and launch CCC instead.
Luckily the shortcuts were user-modifiable. So first thing to do on Windows after installing GPU drivers was to disable this hotkey.
Seems easy to fix
> Windows for backwards compatibility reports 'right-alt' as 'alt+control'.
There’s your problem, right there
> Windows for backwards compatibility reports 'right-alt' as 'alt+control'.
There’s your problem, right there
The backwards compatibility is for physical keyboards. So that a keyboard with just one alt can still trigger polish letters.
I don't know how other OSes allow for users to trigger "right-alt" when the keyboard has only one alt character.
I don't know how other OSes allow for users to trigger "right-alt" when the keyboard has only one alt character.
As a Polish Linux user I think I'd switch between mappings in this case. One for typing źdźbłos and żółws, another to interact with shortcut-heavy apps.
I actually do this on two-alt keyboards too, because I like to use either alt for shortcuts.
I actually do this on two-alt keyboards too, because I like to use either alt for shortcuts.
That also works the other way around -- you can use alt+control instead of right alt.
This may make sense to do with some of the more annoying key combinations, e.g. the German layout requires pressing AltGr+7 for '{'. Both keys individually are usually pressed by the right hand, but pressing the combination with the right hand alone is a very uncomfortable hand position.
This may make sense to do with some of the more annoying key combinations, e.g. the German layout requires pressing AltGr+7 for '{'. Both keys individually are usually pressed by the right hand, but pressing the combination with the right hand alone is a very uncomfortable hand position.
The same applies for a bunch of other languages with a character that's "s" with diacritic modifier, and ctrl-s as save isn't as bad - the most horrible case of this that I had was an old version of outlook webmail that I had to use for one client rarely, where ctrl-s was bound to 'send'. With no option to re-bind or disable it. So about half of the time when I'd get to writing an email it got sent in the middle of the sentence right before where a letter ś would be... And since I had to use it rarely, I never got used to it enough to switch keybord layouts.
Yeah, I use EurKEY which gives me Ctrl+Alt+s for ß and has a lot of other Ctrl+Alt special characters but is otherwise a US Layout.
But I must say that most tools on Windows seem to handle it well with AltGr, only Ctrl+Alt is problematic.
But I must say that most tools on Windows seem to handle it well with AltGr, only Ctrl+Alt is problematic.
Really shows how useful macs having 4 modifier keys (versus PC’s 3) is. Also the better (though not perfect) matching of scopes and modkeys: on macs, command / control / option tend to affect different system areas entirely (with command taking precedence, then control, although control and option are rarely used together).
I do like Cmd+c vs Ctrl+c on a mac. On linux I've changed my terminal to use Ctrl+Shift+c instead of Ctrl+c for ^C because I kept accidentally killing programs when trying to copy text with Ctrl+c which works in every app except terminals...
> I do like Cmd+c vs Ctrl+c on a mac.
It goes way beyond that though: if command’s in a shortcut it pretty much guarantees that’s an application / system shortcut, which frees Ctrl to only deal with text control (and literal control codes in the shell).
And thus Option essentially only does alternate characters.
It’s not perfect, mind, for instance the number of keychords means emacs is annoying whether you leave meta on option or move it to command.
It goes way beyond that though: if command’s in a shortcut it pretty much guarantees that’s an application / system shortcut, which frees Ctrl to only deal with text control (and literal control codes in the shell).
And thus Option essentially only does alternate characters.
It’s not perfect, mind, for instance the number of keychords means emacs is annoying whether you leave meta on option or move it to command.
I configured my terminal to copy on mouse release. This allowed to keep Ctrl-C for killing processes while I use Ctrl-V to paste with Ctrl—Shift-V configured to send the original Ctrl-V.
I recently discover that if you remap Ctrl+C to Copy in a Linux terminal, you still get ^C when nothing is selected. It has made the experience so much better.
I personally find the Mac's use of command keys to be horrendous.
Taking a screenshot? Thats the claw handed Cmd+Shift+4 or maybe even Cmd+Ctrl+Shift+4. Why!? Triggering the emoji picker? Cmd+Ctrl+Space. Don't accidentally press Cmd+Option+Space or you get the world's most useless Finder window.
To make this worse, Apple sell a bunch of keyboards without the symbols printed on them. So often you have software telling you to press the ⌥, ^ and ⇧ keys when your keyboard doesn't even have labels for those symbols.
In contrast, Windows has the Windows key for interfacing with the OS and the Ctrl key for interfacing with apps. So much more logical.
Taking a screenshot? Thats the claw handed Cmd+Shift+4 or maybe even Cmd+Ctrl+Shift+4. Why!? Triggering the emoji picker? Cmd+Ctrl+Space. Don't accidentally press Cmd+Option+Space or you get the world's most useless Finder window.
To make this worse, Apple sell a bunch of keyboards without the symbols printed on them. So often you have software telling you to press the ⌥, ^ and ⇧ keys when your keyboard doesn't even have labels for those symbols.
In contrast, Windows has the Windows key for interfacing with the OS and the Ctrl key for interfacing with apps. So much more logical.
[deleted]
TL;DR. Don't use keypress, it's deprecated. Don't use 'keyCode', 'which', 'char' which are all deprecated. Do use 'key'
Another issue I run into is forms that dismiss via keydown and escape. I type in Japanese which means I'm using an IME. An IME, or at least the Japanese IME, you type characters and they appear with possible completions. They haven't actually been given to the app yet. Pressing Escape cancels the completions. But webpages that cancel some model form dialog via escape means that if I press ESC to cancel IME completion (which is common) I also cancel the dialog and lose all input had previously entered into the form.
I'd think this would been solved at the browser level, if the IME is active then don't pass keys to the app but for probably valid reasons that's not what happens.
TL;DR don't use escape to cancel a model form!
edit: apparently there's the 'isComposting' property on the KeyboardEvent to find out if the user is currently using the IME
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
Another issue I run into is forms that dismiss via keydown and escape. I type in Japanese which means I'm using an IME. An IME, or at least the Japanese IME, you type characters and they appear with possible completions. They haven't actually been given to the app yet. Pressing Escape cancels the completions. But webpages that cancel some model form dialog via escape means that if I press ESC to cancel IME completion (which is common) I also cancel the dialog and lose all input had previously entered into the form.
I'd think this would been solved at the browser level, if the IME is active then don't pass keys to the app but for probably valid reasons that's not what happens.
TL;DR don't use escape to cancel a model form!
edit: apparently there's the 'isComposting' property on the KeyboardEvent to find out if the user is currently using the IME
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
Question then - what do you use functionally to replace "Escape" in your daily use? As a native English-speaking engineer, the escape button has a history of doing exactly what you're suggesting it not do going back to the beginning of computing.
The standard behavior of Esc is to abort the current interaction - which is not the same as closing the dialog. For example, if you have a dialog with a drop-down list, and open that list, Esc should close it, not the whole dialog.
In this scenario, the "current interaction" is IME input. The bug is that the page intercepts Esc keypresses intended to be handled by it.
In this scenario, the "current interaction" is IME input. The bug is that the page intercepts Esc keypresses intended to be handled by it.
I haven't checked in a while, but I'm pretty sure the dialog has no idea that the IME is active or not. So the dialog can't handle that situation, and the browser isn't handling it either. The IME/browser should not send escape to the page when canceling an IME selection.
First of all. Don’t put long forms (i.e. more then a couple of inputs; including checkboxes) in a single dialog modal. Second do listen for keypresses on the dialog it self (not window) so that hitting esc on e.g. the URL bar (or the developer console) has no effect on the dialog it self. And thirdly—as parent states—don’t use deprecated properties and listeners, i.e. use `keydown` and `event.key`.
If you follow these three rules feel free to use the esc to close the dialog. I just tested logging `event.key` with hiragana Mozc input device and every keydown while selecting the correct kanji registers as `Process` even cancelling the input with Esc just adds another Process keydown event. I admit it can be frustrating if you double tab Esc accidentally to close the input (second Esc will close the dialog), but that is where rule one comes in, and the accident will only cause the user a minor annoyance.
If you follow these three rules feel free to use the esc to close the dialog. I just tested logging `event.key` with hiragana Mozc input device and every keydown while selecting the correct kanji registers as `Process` even cancelling the input with Esc just adds another Process keydown event. I admit it can be frustrating if you double tab Esc accidentally to close the input (second Esc will close the dialog), but that is where rule one comes in, and the accident will only cause the user a minor annoyance.
Not sure if I agree with this summary of my article. For most web apps with relatively few keyboard shortcuts, I would actually recommend to use keypress. keyCode/which/charCode work when used with keypress.
The article mentions an open-source example that does it this way and works fine on international layouts: Discourse
The article mentions an open-source example that does it this way and works fine on international layouts: Discourse
Well, maybe you should go edit MDN because it has a giant red "DEPRECATED" at the top of keypress
https://developer.mozilla.org/en-US/docs/Web/API/Document/ke...
https://developer.mozilla.org/en-US/docs/Web/API/Document/ke...
Never said it wasn't deprecated. It still works much better than using keydown with keycode. For most apps and layouts, it's a sufficient solution.
What works best is to use `keydown`[1] with `keyboardEvent.key`[2]. Chrome took a while to implement `keyboardEvent.key` and I’m guessing that delay hindered adoption, but for the past few years (since the 5 year old Chrome 51) it is objectively the best—and arguably the only robust—way to figure out which key the user typed.
1: https://developer.mozilla.org/en-US/docs/Web/API/Element/key...
2: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
1: https://developer.mozilla.org/en-US/docs/Web/API/Element/key...
2: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
Thanks, going to add that to a modal today.
Or even better, do not put form in a closable dialog / "things"
As a kid, I remember being utterly confused, when most games with a console would have the key ` to open it. WTF is the key ` and where is it?
For a kid it wasn't that easy to understand that there are such things as different keyboard layouts. Turns out that ` is a single key press to the left of the '1', in English, while it is a bit obscure character to write in other languages. In mine, you have º and ª in that place... so no ` at sight.
But game devs assume that ` is just a keypress away in a confortable area of the keyboard, and it became the de facto way to open in-game consoles. Oh well.
For a kid it wasn't that easy to understand that there are such things as different keyboard layouts. Turns out that ` is a single key press to the left of the '1', in English, while it is a bit obscure character to write in other languages. In mine, you have º and ª in that place... so no ` at sight.
But game devs assume that ` is just a keypress away in a confortable area of the keyboard, and it became the de facto way to open in-game consoles. Oh well.
Also programming languages used it as an alias for exec. Even if you have a ` key, on some layouts (such as the Irish keyboard layout) it can be a weird key to type due to dead key behaviour, often requiring multiple presses to respond and eating the next keypress.
yeah.. i never use js template strings because of that frigging unusable backtick character.
Ist so hard to type on my layout, that its just not worth it -_-
I remember that too.
But the console you only open sometimes.
But everyday(!), I have to use {[(| ... and they are just awkward to reach on a german layout.
But the console you only open sometimes.
But everyday(!), I have to use {[(| ... and they are just awkward to reach on a german layout.
Last time I needed a new laptop (my old one died) I took a 8 hour train to travel to the Netherlands from Munich instead of back home to Berlin (where I live) just so I could visit a store that has laptops with a non German layout (US international). The only way to get a non German keyboard in Germany is to order them online and wait for a week+ (typically) for that to ship internationally (because they don't stock these locally). That was clearly unacceptable. So, 8 hour train ride it was because I needed a replacement in a hurry and I got to visit my parents. Win win.
The alternative would have been buying a laptop with literally every key I care about in the wrong place in some local store. It's great that alternate keyboard layouts are available to those that actually need/want them but it really sucks that you get locked into these choices just because of where you are. Local shop owners don't seem to have any commercial sense whatsoever. Here's a genius idea in a city full of expats (Berlin, Munich), you know, maybe stock a few laptops with international keyboards. Even the local Apple store doesn't do that. And any time you go there, a very meaningful percentage of the customers is clearly not German.
Every non German buying a German keyboard because they have to is basically an unhappy customer. I know loads of foreigners here moaning about German keyboards. I've never met a non German that actually prefers having keys in the wrong place. That's not a thing; it's bloody annoying. It's equally annoying in other countries where expats live. E.g. French keyboard layouts are worse, AZERTY instead of QWERTY. At least in Germany you get QWERTZ (Y and Z are swapped). I've actually met quite a few German programmers that remap their keyboards so they can program without having to use four fingers to produce a single key-press.
The alternative would have been buying a laptop with literally every key I care about in the wrong place in some local store. It's great that alternate keyboard layouts are available to those that actually need/want them but it really sucks that you get locked into these choices just because of where you are. Local shop owners don't seem to have any commercial sense whatsoever. Here's a genius idea in a city full of expats (Berlin, Munich), you know, maybe stock a few laptops with international keyboards. Even the local Apple store doesn't do that. And any time you go there, a very meaningful percentage of the customers is clearly not German.
Every non German buying a German keyboard because they have to is basically an unhappy customer. I know loads of foreigners here moaning about German keyboards. I've never met a non German that actually prefers having keys in the wrong place. That's not a thing; it's bloody annoying. It's equally annoying in other countries where expats live. E.g. French keyboard layouts are worse, AZERTY instead of QWERTY. At least in Germany you get QWERTZ (Y and Z are swapped). I've actually met quite a few German programmers that remap their keyboards so they can program without having to use four fingers to produce a single key-press.
I moved to Iceland a year ago, and brought my PC and my laptop with me. I am confounded by icelandic (nordic in general) keyboards. I can understand their use for a non-technical person, but even keys such as @ are obscured behind "Alt Gr" which is a secondary right side only alt-key? And the position of braces, brackets, and parantheses is also clearly an afterthought. Obviously, years of muscle memory are hard to replace, so I've continued to use my US keyboards.
But there's a problem. I want to spell people and places' names correctly, and on my PC that means I have to swap input locales often in order to type proper icelandic characters like ð, ö, þ, æ, í etc. This is annoyingly hard on a keyboard that doesn't support them natively! I will give apple some credit here - it's incredibly easy and intuitive to type foreign characters on a US keyboard just by holding down 'i' for example, if you only occasionally need to use them. Windows requires you to either learn the old-school way of holding alt, and typing the ascii code on the number pad, or hot-swap input languages. I know German uses far fewer unique characters, but how do you cope with that problem when you need German characters like.. sharp S, oumlaut, etc?
But there's a problem. I want to spell people and places' names correctly, and on my PC that means I have to swap input locales often in order to type proper icelandic characters like ð, ö, þ, æ, í etc. This is annoyingly hard on a keyboard that doesn't support them natively! I will give apple some credit here - it's incredibly easy and intuitive to type foreign characters on a US keyboard just by holding down 'i' for example, if you only occasionally need to use them. Windows requires you to either learn the old-school way of holding alt, and typing the ascii code on the number pad, or hot-swap input languages. I know German uses far fewer unique characters, but how do you cope with that problem when you need German characters like.. sharp S, oumlaut, etc?
I am a non German, but I spent more time using German layout than the US one.
The killer feature of German keyboard: it is so natural for vim (and IDEs with vim emulation)
- the registers "+, "*, "~ are on the same key
- `,` and `;` for backward and forward searching are on the same key
- the macro operations `q` and `@` are also on the same key
- `^` for the line beginning is the key left to `1`, which also makes sense for `Ctrl+^` to switch recent buffers.
- the registers "+, "*, "~ are on the same key
- `,` and `;` for backward and forward searching are on the same key
- the macro operations `q` and `@` are also on the same key
- `^` for the line beginning is the key left to `1`, which also makes sense for `Ctrl+^` to switch recent buffers.
I would guess that the amount of people who care about which keyboard layout
they use, don't use the local keyboard layout, and require appropriate labeling
of keys (i.e. don't touch type) at the same time isn't that high. I can imagine
how annoying it must be to be in that group, though.
There are few million people in Berlin. A couple of hundred of thousand of them are Turkish or Russian minorities. And another few hundred thousand expats are working in the tech industry from all over the world. Most coffee shops in my area don't even have German speaking staff; much to the annoyance of some of the locals.
Some, of those people buy locally and suffer the bad experience of dealing with a sub optimal keyboard. But a lot of them take their money abroad. Local businesses are missing out on that, which IMHO is kind of stupid.
Some, of those people buy locally and suffer the bad experience of dealing with a sub optimal keyboard. But a lot of them take their money abroad. Local businesses are missing out on that, which IMHO is kind of stupid.
You might find https://neo-layout.org very useful for daily use. They provide a version that bolts the utility layers onto qwertz as well.
I think this is an interesting cultural difference.
There is such a thing as a Dutch keyboard layout and keyboard, but almost no one in the Netherlands uses them, as well as configuring one's system to be in Dutch, because it leads to such problems as described.
My entire system is configured in U.S. English, though most of the spelling I use is closer to U.K. English, but I find that it leads to the least problems in practice.
If it were configured to be Dutch, then troubleshooting would be a mess. — this is a common mentality in the Netherlands to never have any electronics or website configured to be Dutch, even when the option allow itself.
Special characters are usually input using the U.S. International layout which which allows one to type, say, “schöne scheiße”. quite easily.
There is such a thing as a Dutch keyboard layout and keyboard, but almost no one in the Netherlands uses them, as well as configuring one's system to be in Dutch, because it leads to such problems as described.
My entire system is configured in U.S. English, though most of the spelling I use is closer to U.K. English, but I find that it leads to the least problems in practice.
If it were configured to be Dutch, then troubleshooting would be a mess. — this is a common mentality in the Netherlands to never have any electronics or website configured to be Dutch, even when the option allow itself.
Special characters are usually input using the U.S. International layout which which allows one to type, say, “schöne scheiße”. quite easily.
Yeah, sorry but the continental European keyboard maps with those keys in the number row suck. There's no ifs or buts about that.
I have learned on the US keyboard and keep using it more or less.
I have learned on the US keyboard and keep using it more or less.
We all suffer from character blindness of some sort. For you: ` - that thing isn't formally defined in English either as far as I know.
In English we don't have any diacritics. We do have a few extra symbols, beyond the alphabet for certain situations. Quotations ... " ... meh should be 66 99 and that will be fixed up by DTP software. We use ' to denote a dropped letter - abbreviation. There are a few others. I won't dwell on "thorne" and ligatures and other oddities.
I do not know of any reason to write ` - it is not an apostrophe, which is: '. What is it?
In English we don't have any diacritics. We do have a few extra symbols, beyond the alphabet for certain situations. Quotations ... " ... meh should be 66 99 and that will be fixed up by DTP software. We use ' to denote a dropped letter - abbreviation. There are a few others. I won't dwell on "thorne" and ligatures and other oddities.
I do not know of any reason to write ` - it is not an apostrophe, which is: '. What is it?
ASCII has a limited number of characters, so they designed it so some do double-duty. The grave could be a grace accent if you backspaced over a letter, or it could be an opening quote mark. The apostrophe was the reverse: it could be the acute accent. The fonts were drawn so these characters were angled enough to be accents, but also looked like quote marks. The apostrophe wasn't a vertical prime sign. Angle brackets and greater/lesser-than also double-up.
It's the grave accent - pretty rare in English outside of loan words from other languages.
https://en.wikipedia.org/wiki/Grave_accent#English
https://en.wikipedia.org/wiki/Grave_accent#English
Touché
I am not claiming to be a learnèd man, but I believe that is an acute accent, not a grave accent.
You are absolutely correct. Je suis désolé.
I think back in the day (typewriters thru... 90s?) you wrote quoted text `like this.'
This is how both TeX and m4 do quoting by default so presumably common when they were created (mid-eighties and early seventies respectively IIRC)
It’s an ASCII approximation of the proper typography for single quotes (except when you’d use inverted quotes for some reason, not sure how common it is in English).
Similarly, LaTeX uses `` and ‘’ for double quotes because the opening and closing symbols are not the same in properly typeset texts.
Similarly, LaTeX uses `` and ‘’ for double quotes because the opening and closing symbols are not the same in properly typeset texts.
This still seems to be "house style" for a certain brand of "old school" open source mailing list.
Note that ' is not technically a proper apostrophe which would be ’ instead. It only came to be thanks to typewriters having limited character space.
> What is it?
Not sure if you meant this literally, but I've seen it refered to as a back tick. As to what it's for, I have no idea either. I can't recall ever seeing it outside of programming.
Not sure if you meant this literally, but I've seen it refered to as a back tick. As to what it's for, I have no idea either. I can't recall ever seeing it outside of programming.
On a mechanical typewriter you'd have a button that would "revert" the position you'll write to by one character - also known as backspace.
So if you pressed backspace followed by "`", you'd give the last character a grave accent.
That's my theory for it being called backtick anyways.
Nowadays you could configure your input method to make that key give the next character a grave accent
So if you pressed backspace followed by "`", you'd give the last character a grave accent.
That's my theory for it being called backtick anyways.
Nowadays you could configure your input method to make that key give the next character a grave accent
I'm pretty sure it's called "back" because of the direction it tilts.
My mum had a mechanical typewriter and yes it would do that. However English has no formal diacritics. We do have shit loads of borrow words from French and others that do have them.
If the back tick on the en_GB keyboard is a sop for the grave accent, then why do we not have an acute accent available as well? or a cedilla for that matter?
If the back tick on the en_GB keyboard is a sop for the grave accent, then why do we not have an acute accent available as well? or a cedilla for that matter?
` is bad because it looks like '.
A lot of programming resources I've seen have an explicit explanation that the backtick is a different character than the single quote. Better yet, some fonts make the two almost identical.
A lot of programming resources I've seen have an explicit explanation that the backtick is a different character than the single quote. Better yet, some fonts make the two almost identical.
> In mine, you have º and ª in that place...
Out of curiosity, what keyboard layout do you use?
Out of curiosity, what keyboard layout do you use?
Don't know about parent, but latin-american keyboard is like that.
[deleted]
It's not just international keyboards that are affected by this. I'm a Dvorak user so I run into these issues from time to time.
As the article explains, there is a difference between the physical keyCode and character it corresponds to. Which to use really depends on what it is being used for, and there are situations for both. The article suggests checking the character typed, but this is not always the correct way to do it.
For instance, the most annoying are games which default to WASD based on the letter typed and not the physical keys (I've seen this both in web app and native games). Using WASD based on letters simply does not make sense because the whole purpose is to mimic arrow keys. If you base it off of letters typed, then on Dvorak it's like if you used ,A;H on Qwerty which makes absolutely no sense for directional navigation.
For shortcuts where the letter has a meaning, then you might want to look at the actual character. But beware that even alphanumeric keys are not always in the same place because of layouts such as Dvorak and Colemak.
As the article explains, there is a difference between the physical keyCode and character it corresponds to. Which to use really depends on what it is being used for, and there are situations for both. The article suggests checking the character typed, but this is not always the correct way to do it.
For instance, the most annoying are games which default to WASD based on the letter typed and not the physical keys (I've seen this both in web app and native games). Using WASD based on letters simply does not make sense because the whole purpose is to mimic arrow keys. If you base it off of letters typed, then on Dvorak it's like if you used ,A;H on Qwerty which makes absolutely no sense for directional navigation.
For shortcuts where the letter has a meaning, then you might want to look at the actual character. But beware that even alphanumeric keys are not always in the same place because of layouts such as Dvorak and Colemak.
No, `keyCode` can also change with layout. Since you mentioned WASD, ‘W’ on a US layout has `keyCode` 87. Select a French layout, and the same physical key now has `keyCode` 90.
If you're using `keyCode` for anything, you're doing it wrong. There's a reason it's marked ‘legacy’.
Physical key position is the UI Event ‘code’, which is in this example will be "KeyW" regardless of layout. This field is essentially 1:1 with hardware HID codes (as used by USB and Bluetooth keyboards).
If you're using `keyCode` for anything, you're doing it wrong. There's a reason it's marked ‘legacy’.
Physical key position is the UI Event ‘code’, which is in this example will be "KeyW" regardless of layout. This field is essentially 1:1 with hardware HID codes (as used by USB and Bluetooth keyboards).
I've used dvorak and now workman and I don't mind the shortcuts moving around.
The biggest annoyance for me is if you want to sometimes use hardware-level dvorak or another layout (which expects software-level qwerty) and sometimes use it in software. Like, if your keyboard runs QMK but you use it with a laptop and might want to use the laptop's built-in keyboard if you take it on the go.
GTK also has some weird issues if you have multiple layouts enabled where the shortcuts are in the wrong place and don't all work (happens in Dino and Gedit). So, I now have only qwerty enabled in Sway and I'll just edit the config if I ever need to change virtual layouts instead of doing it with a couple keypresses.
The biggest annoyance for me is if you want to sometimes use hardware-level dvorak or another layout (which expects software-level qwerty) and sometimes use it in software. Like, if your keyboard runs QMK but you use it with a laptop and might want to use the laptop's built-in keyboard if you take it on the go.
GTK also has some weird issues if you have multiple layouts enabled where the shortcuts are in the wrong place and don't all work (happens in Dino and Gedit). So, I now have only qwerty enabled in Sway and I'll just edit the config if I ever need to change virtual layouts instead of doing it with a couple keypresses.
Does windows a way to simultaneously use different layouts for different connected devices? It's really annoying shifting between my Japanese USB keyboard and English laptop. In Ubuntu I had startup script to detect input devices IDs by name and force different layouts, but even that was a bit of a hack.
Judging by the comments here, looks like we’re globally a rare breed that want absolute priority for keytop labeling over software configuration items.
Another Dvorak typist here! Personal funny anecdote: I learned vim modal navigation after I learned Dvorak, and never bothered to remap the keys. Totally debilitating if I'm using a coworkers QWERTY keyboard for vim navigation, but at least I can still navigate on remote servers without reconfiguring anything!
> For instance, the most annoying are games which default to WASD based on the letter typed and not the physical keys
Is it even possible to do anything else? I can’t imagine keyboards report their physical layout..
Is it even possible to do anything else? I can’t imagine keyboards report their physical layout..
The only possibility is to allow the user to assign custom keys, which is pretty common.
It’s impossible to know the physical layout for absolute certainty. For all you know, my “Enter” could be a pedal under the desk.
It’s impossible to know the physical layout for absolute certainty. For all you know, my “Enter” could be a pedal under the desk.
In X11 with the Xkb extension you can configure simplified vector drawings of your input devices, which any application can query. It is intended that applications use these drawings in their help systems and tutorials, as well as in their key binding editors. Few applications bother though.
https://www.x.org/releases/current/doc/libX11/XKB/xkblib.htm...
https://www.x.org/releases/current/doc/libX11/XKB/xkblib.htm...
Scancodes from PS/2 keyboards are layout-based.
Physical layout is mostly irrelevant, different keycap label arrangements use the same keycodes - the input system in your OS or application uses a keyboard layout to translate those into what you want to type.
Windows, macOS and the various input libraries on Linux provide ways to query the key map - and a number of games do use this to provide localized bindings (Ubisoft and Blizzard are notorious for doing this right, something I appreciate as a dvorak user who hates dealing with rebinding or constantly having to toggle layouts). As far as the browser there is coming support for reading the keyboard layout as well: https://developer.mozilla.org/en-US/docs/Web/API/Keyboard/ge...
Windows, macOS and the various input libraries on Linux provide ways to query the key map - and a number of games do use this to provide localized bindings (Ubisoft and Blizzard are notorious for doing this right, something I appreciate as a dvorak user who hates dealing with rebinding or constantly having to toggle layouts). As far as the browser there is coming support for reading the keyboard layout as well: https://developer.mozilla.org/en-US/docs/Web/API/Keyboard/ge...
Starcraft II had a grid (I don't remember the actual name) mode keyboard layout that worked perfectly with Dvorak without having to remap keys.
Other games like the Java version of minecraft didn't work with Dvorak when I tried them. Even with key remapping.
Other games like the Java version of minecraft didn't work with Dvorak when I tried them. Even with key remapping.
A few games map based on the key codes. For example, SC2 will get grid layout right on Dvorak or Colemak without any remapping. It did take me directly emailing a designer, who passed it on to the developers, though. ;)
Yes, the UI Events ‘code’ field represents the physical key (essentially 1:1 with USB hardware codes). The key that's labelled ‘W’ on a US keyboard and ‘Z’ on a French keyboard and ‘Ц’ on a Russian keyboard and ‘て’ on a Japanese keyboard (and so on) will have code=="KeyW" in all cases.
Normally, keyboards report data to the computer which represents the location of a key on a standard keyboard. The OS translates to characters based on configured layout. The actual letters printed on the key caps are just decorative.
If you type WASD on a US layout USB keyboard, the computer will receive key codes 26, 4, 22, 7.
If you type ZQSD on a French keyboard you get exactly the same result.
So if you are writing a game, you might listen for codes 26, 4, 22, 7 and these will be in the sample place on the keyboard regardless of layout. You can ask the OS to translate these codes to letters for help text.
(Some of the details here are omitted—the codes above are USB HID codes, but those go through an additional OS-specific translation table before they are sent to your program.)
If you type WASD on a US layout USB keyboard, the computer will receive key codes 26, 4, 22, 7.
If you type ZQSD on a French keyboard you get exactly the same result.
So if you are writing a game, you might listen for codes 26, 4, 22, 7 and these will be in the sample place on the keyboard regardless of layout. You can ask the OS to translate these codes to letters for help text.
(Some of the details here are omitted—the codes above are USB HID codes, but those go through an additional OS-specific translation table before they are sent to your program.)
> Is it even possible to do anything else? I can’t imagine keyboards report their physical layout..
You can easily ask the OS what layout is being used or even ask the user.
You can easily ask the OS what layout is being used or even ask the user.
Is there a programmatic way to figure out what letter corresponds to a given keycode without that key being pressed? Because you may have to display that info somewhere to give an indication what the user has to press.
Not that I know of.
Also, not that “alt-s” will produce an s character on a US keyboard on windows, but will not produce an s on MacOS with a US layout - alt-anything will produce all sorts of interesting characters on MacOS.
Also, not that “alt-s” will produce an s character on a US keyboard on windows, but will not produce an s on MacOS with a US layout - alt-anything will produce all sorts of interesting characters on MacOS.
There are APIs available on all major OSs that do this. Example:
https://developer.apple.com/documentation/coreservices/13905...
My memory is that if you press option E on a Mac, the translation function reports a non-zero state but no character output. You can detect this and call the translation function again with a space to get the diacritic by itself.
https://developer.apple.com/documentation/coreservices/13905...
My memory is that if you press option E on a Mac, the translation function reports a non-zero state but no character output. You can detect this and call the translation function again with a space to get the diacritic by itself.
Yes. You have to dig a bit to find these APIs, and they are OS-specific (and the scan codes reported by the OS are OS-specific too, even though most keyboards are USB HID these days).
Here is the function for macOS:
https://developer.apple.com/documentation/coreservices/13905...
Here is the function for macOS:
https://developer.apple.com/documentation/coreservices/13905...
OS X's solution works perfectly: Dvorak + QWERTY shortcuts layout. It's brilliant and elegant, Windows needs to implement the same thing (revert to QWERTY when holding the ctrl or windows keys).
On a tangent, why are non-qwerty keyboards so poorly designed for programming? And specifically, why is apple’s azerty layout so terrible?
Just look at this image: https://i.stack.imgur.com/3LL8a.png
Can you find the [ and ] keys? If you’re having trouble, it’s because you have to use 2 (two!) modifier keys and activate the ( or ) keys, which themselves are clumsily placed. This cannot be typed one-handed in a comfortable way. Apple’s azerty layout is unique in this, as regular azerty puts those keys in a more sensible place. I keep wondering: why does apple make me do a Vulcan nerve pinch every time I want to index an array?
Just look at this image: https://i.stack.imgur.com/3LL8a.png
Can you find the [ and ] keys? If you’re having trouble, it’s because you have to use 2 (two!) modifier keys and activate the ( or ) keys, which themselves are clumsily placed. This cannot be typed one-handed in a comfortable way. Apple’s azerty layout is unique in this, as regular azerty puts those keys in a more sensible place. I keep wondering: why does apple make me do a Vulcan nerve pinch every time I want to index an array?
It's the other way around. The keyboard was the foundation for the programming languages and shortcuts, like moving with hjkl in vim. No German keyboard user would have created a language like C with curly braces, when you would break your fingers typing this (alt 8 is {, alt 9 is }, and alt+5 is [, alt+6 is ] ).
I use a US keyboard for that exact reason
I use a US keyboard for that exact reason
I reassign my Caps lock key as a third level modifier. That way I can type { with Caps Lock + 7. Caps lock is so large I can comfortably use my pinky and ring finger to press and hold it, while I use my right hand to press 7, 8, 9 or 0 for {, [, ], } respectively.
I do something similar: http://blog.pythonaro.com/2020/06/better-access-to-special-c...
Aah, this explains why we have two keyboard layouts in Poland.
Original keyboards (up until 1980s) had special polish letters like ąęśćżń on dedicated keys, and various characters like [{$ moved around.
That is called „Polish” layout.
Then, since 1990 we have „Polish (programmer’s)” , which is essentially the american keyboard and local characters hidden under alt-right.
Literally everyone uses „Polish (programmers)” now, and you just need to remember to choose this, and not the regular „Polish” in system settings :)
Original keyboards (up until 1980s) had special polish letters like ąęśćżń on dedicated keys, and various characters like [{$ moved around.
That is called „Polish” layout.
Then, since 1990 we have „Polish (programmer’s)” , which is essentially the american keyboard and local characters hidden under alt-right.
Literally everyone uses „Polish (programmers)” now, and you just need to remember to choose this, and not the regular „Polish” in system settings :)
I think the answer is that their engineers overwhelmingly use the English layout keyboards and work in Cupertino. Most improvements to coding on a Mac I have seen have a design-for-self element where apple employees are eating their own dog food and want to improve the taste.
C was famously designed in Murray Hill on a system with Teletype 37s, which featured then-fairly-novel { and } keys (as it so happens, the shifted versions of [ and ]).
‘Happens’ is understating it. ‘[’ is ASCII 0x5B and ‘{’ is ASCII 0x7B, and the Teletype 37 was entirely electromechanical. For those unfamiliar, see https://en.wikipedia.org/wiki/Bit-paired_keyboard
QWERTY is awful for programming. I use https://www.kaufmann.no/roland/dvorak/. which puts control characters on the number row. `&[{}(=*)+]` is 1 to 0.
Most keyboard-layouts predate programming-languages, because they were designed for typewrites decades before the first modern computers even existed. So there did gave much to usage of special chara back then. Additionally most languages were designed by americans, on US-layout, which had a great impact on usages of different char in our digital world. Like for example the usage of @, which AFAIK was only used for e-mail because there was no other free char on the developers keyboard available.
> Like for example the usage of @, which AFAIK was only used for e-mail because there was no other free char on the developers keyboard available.
'@' meant 'at' looong before e-mail was invented.
'@' meant 'at' looong before e-mail was invented.
Yes, in english language. Other languages have/had different names, if they even knew it at this point. There was of course a reason why the @ was on the english keyboard-layout, but it was a very different reason from the later usage as location/user-reference. Point is, if e-mail would have been invented in a different culture, there would be a good chance that the symbol wasn't even on their keyboard at the time and a different symbol would likely have been used.
But traditionally mainly (only?) in the context of "at [price per unit]", not "at [location]".
In American usage, it has had widespread use as shorthand for “at” in many different contexts, not just in terms of price per unit fir quite a while; some of them.may have been catalyzed by thr usage in email, but I think enough are older that email fits into an existing pattern rather than creating a new one.
Honestly that's one of the reasons I'm happy with the Logitech Craft: it lets me use a proper Azerty layout yet silent like the Apple keyboards (plus I can control both my computers from a single keyboard, but that's more an edge case).
Just get this one https://www.apple.com/ca/shop/product/MLA22C/A/magic-keyboar...
Why is it so bad? Because folks keep on buying it. So there's no demand to improve it.
Why is it so bad? Because folks keep on buying it. So there's no demand to improve it.
I remapped all those keys to Tab+righthand, so to type the curly brace I press Tab+j. It's fantastic.
The neo2 layout took this into account, (), [], {} and <> are under your strongest fingers.
> What baffles me is that the problem exists in apps used by millions of people every day, developed by gigantic corporations who pride themselves with having the best engineers in the world. Why is this baffling? Because the underlying technical issues are rather trivial!
> Hint for developers: Switch your computer’s keyboard layout to something other than US to debug your application’s shortcut handling on different layouts.
The problem with this and all the other X is broken and should be tested articles is that the testing burden is already enormous. Plenty of companies don’t even test with Firefox and/or Safari.
That’s really the problem that needs to be solved. How to reduce the testing burden.
> Hint for developers: Switch your computer’s keyboard layout to something other than US to debug your application’s shortcut handling on different layouts.
The problem with this and all the other X is broken and should be tested articles is that the testing burden is already enormous. Plenty of companies don’t even test with Firefox and/or Safari.
That’s really the problem that needs to be solved. How to reduce the testing burden.
For a 10-person startup, that's fair. For a company like Google , with offices in Germany and France and hundreds of engineers from any nationality, not so much. Other companies fall somewhere in between based on their headcount and global reach.
Big companies aren’t huge for the sake of being huge. They employ so many people because they have so much work to do.
They still employ as few people as they can get away with.
They still employ as few people as they can get away with.
Plus it's all about profit margins. Investing in tons of testing for not enough return from users means they just won't do that.
I'd imagine you'd need multi-lingual testers to use the product too, not just a native speaker given a foreign keyboard. There's no way to find bugs an average user would face with normal use.
I'd imagine you'd need multi-lingual testers to use the product too, not just a native speaker given a foreign keyboard. There's no way to find bugs an average user would face with normal use.
I don't think testing with a non-US region settings and a non-English language is a huge burden. As a regular user of “internationalised” software, it's really obvious when the people who wrote it do not speak more than one language, or only considered a single-country perspective.
Monolinguals, especially those living in the United States, are a minority globally. If you're going to develop all software in the United States, please at least make it work for the rest of us.
Monolinguals, especially those living in the United States, are a minority globally. If you're going to develop all software in the United States, please at least make it work for the rest of us.
If there was a standard way to define hotkey bindings, a simple linter could take care of that. It just shows how far we still have to go in terms of good UI creation tooling.
This is part of why I’d like to see more VSCode-as-an-OS (disclaimer work on VSCode)... imagine writing only the code to go from bytes on disk => view and back, and getting for free: version control, command palette, keybindings, Windows/Mac/Linux/Web support, file explorer, tabs, split views, hot exit, etc etc etc.
We already have a perfectly good OS that does all that. It's called Emacs.
This is the real solution. Providing a native API with i18n built in would quickly start resolving this issue.
It reminds me of developers who want to capture link clicks for internal navigation but acccidently block right or middle click as well because it is the easy thing to do.
If we provide APIs that make the right thing the easiest we will have more websites that do the right thing.
It reminds me of developers who want to capture link clicks for internal navigation but acccidently block right or middle click as well because it is the easy thing to do.
If we provide APIs that make the right thing the easiest we will have more websites that do the right thing.
I agree to some extent. However, I have outlined a few very simple approaches. At the very least, developers could stop using special characters for their most important shortcut bindings.
My favorite recent WTF:
On French keyboard, the numbers 0-9 and special chars (#$&@...) are swapped, so you need "shift+<num>" to type in a number. Effect on the web compat:
A phone number validator on French lowcost railway website was built/tested with French keyboard only; they were checking input codes in JS on each keypress and only allowing the presses of certain keys with shift enabled. Since you can't type a number on QWERTY with shift enabled, I was unable to complete the form until I realized what's up by reading the JS and switched to AZERTY layout.
(copy-pasting into the input didn't work either)
---
Unrelated aside: as I was raised in Poland which is based on US QWERTY and all programs using US shortcuts (with the only quirk being AltGr mentioned in other comments), I was mind blown than in other countries it's customary to localize shortcuts.
For example in Spain in notepad.exe, save is not CTRL-S but CTRL-G ("guardar").
In France, you don't bold in Excel with CTRL-B, you bold with CTRL-G ("grossir"). For some reason Excel online only lets me use the FR version despite settungs all possible locale settings to en and this drives me nuts.
On French keyboard, the numbers 0-9 and special chars (#$&@...) are swapped, so you need "shift+<num>" to type in a number. Effect on the web compat:
A phone number validator on French lowcost railway website was built/tested with French keyboard only; they were checking input codes in JS on each keypress and only allowing the presses of certain keys with shift enabled. Since you can't type a number on QWERTY with shift enabled, I was unable to complete the form until I realized what's up by reading the JS and switched to AZERTY layout.
(copy-pasting into the input didn't work either)
---
Unrelated aside: as I was raised in Poland which is based on US QWERTY and all programs using US shortcuts (with the only quirk being AltGr mentioned in other comments), I was mind blown than in other countries it's customary to localize shortcuts.
For example in Spain in notepad.exe, save is not CTRL-S but CTRL-G ("guardar").
In France, you don't bold in Excel with CTRL-B, you bold with CTRL-G ("grossir"). For some reason Excel online only lets me use the FR version despite settungs all possible locale settings to en and this drives me nuts.
> For example, on my German layout, / is produced via Shift+7.
This is my #1 annoyance with German keyboards as someone who learned a UK layout and who needs to do lots of programming and terminal hacking (#2 is the swapping of Y and Z). I take it this layout was invented before Unix and its heavy use of forward slashes, but it does show how shortcuts are rather discriminatory. I know more than a few Germans who use UK or US keyboards because they dislike this unhappy feature.
This is my #1 annoyance with German keyboards as someone who learned a UK layout and who needs to do lots of programming and terminal hacking (#2 is the swapping of Y and Z). I take it this layout was invented before Unix and its heavy use of forward slashes, but it does show how shortcuts are rather discriminatory. I know more than a few Germans who use UK or US keyboards because they dislike this unhappy feature.
> I take it this layout was invented before Unix and its heavy use of forward slashes
My guess would be that Unix chose many of its special characters and keyboard shortcuts precisely because they were easy to type on a US keyboard.
My guess would be that Unix chose many of its special characters and keyboard shortcuts precisely because they were easy to type on a US keyboard.
I'm Chilean and I use the ANSI US layout because /, < and > are much easier to type than using ISO keyboards.
When I need to type Spanish characters like áéíóú, ñ, etc. I switch to latin american ISO layout using WIN + Spacebar and then switch back.
When I need to type Spanish characters like áéíóú, ñ, etc. I switch to latin american ISO layout using WIN + Spacebar and then switch back.
Why not just use US Intl, and use ALT GR to produce á, é, í, ó, ú and ñ, along with æ, ø and å?
I have a strange ISO/ANSI US keyboard, with an ANSI left shift and an ISO enter key.
I have a strange ISO/ANSI US keyboard, with an ANSI left shift and an ISO enter key.
I didn't know about the US intl layout when I decided to make the switch, and I don't know if it's worth to learn it now.
I used to switch between US and DK layouts, it's just so much easier to just have one layout. In my opinion, learning US Intl is worth it. Besides, it's pretty predictable for Spanish characters: á = altgr+a, é = altgr+e and so on.
Yeah it's great for Spanish. But I found that knowing (and using) native layout is more valuable to me because when I need to type on someone else's keyboard I'm not lost and can still touch type. If you never need to do this US international is indeed superior layout.
Trying to remember more than two layouts becomes confusing very fast. AZERTY and QWERZ are the two worst ones, fortunately I never need to use those.
Trying to remember more than two layouts becomes confusing very fast. AZERTY and QWERZ are the two worst ones, fortunately I never need to use those.
The British/Irish ISO layouts are reasonable. They are very close to the US layout, but gain the additional key.
I don’t think UK/ISO and US are close? Especially backquote between LShift and Z feels awkward if you’re used to ANSI.
These keys are in different positions: "@#~\|
These keys are present on the UK keyboard, but not the US: £¬
Compared to every other common ISO keyboard layout, ISO UK and ANSI are very similar. For non-programmers, ", @ and (nowadays) # are the ones that matter. For a programmer used to an ISO keyboard, the UK layout may well be a better choice than the US ANSI one. (US ISO would be a good choice, but the extra key seems to duplicate symbols already present on the layout).
These keys are present on the UK keyboard, but not the US: £¬
Compared to every other common ISO keyboard layout, ISO UK and ANSI are very similar. For non-programmers, ", @ and (nowadays) # are the ones that matter. For a programmer used to an ISO keyboard, the UK layout may well be a better choice than the US ANSI one. (US ISO would be a good choice, but the extra key seems to duplicate symbols already present on the layout).
In intellij this was a bit frustrating to me, you can do ctrl-shift-`/` to block-comment (in german keyboard: ctrl+shift+shift+7). How do I double-shift?
I know you can configure that in IJ but I'm too lazy to do that, especially if there are many keys to remap.
So now I have a keyboard with UK Layout.
I know you can configure that in IJ but I'm too lazy to do that, especially if there are many keys to remap.
So now I have a keyboard with UK Layout.
Same problem with latin american keyboards found just a few kilometers south the US. If I remember correctly, the default modifier key in VIM is next to imposible to press on a l-a keyboard. It was ` ?
You mean the default prefix key. You really really don’t need to use prefix keys, like at all, in normal Vim use.
I’ve gotten so used to switching between keyboard layouts when moving from e-mail to coding that I don’t think about this much, but it can be tremendously irritating when I’m on a new machine or just forget to switch.
(pt-PT keyboard, parenthesis and brackets are either an off-by-one or require Alt-Gr+Shift to type.)
Using a US keyboard layout for a while really drives home how much it influenced popular CLI character choices (like path separators, pipe characters, etc.), too.
(pt-PT keyboard, parenthesis and brackets are either an off-by-one or require Alt-Gr+Shift to type.)
Using a US keyboard layout for a while really drives home how much it influenced popular CLI character choices (like path separators, pipe characters, etc.), too.
I mostly write in English (plus Clojure, shell, and C#), but often also in Spanish, French and Finnish. I've found that a standard QWERTY/US layout with a Compose key is the best option. It gives you a decent layout for coding and shell related characters, and all diacritics (and plenty more) are a 3 keystroke chain away (with no chording). Even when writing French, which requires a lot of accents, I find it more fluid than needing to switch to (the completely awful) AZERTY layout.
I like the default Mac US/International English/British layouts (they're almost the same as each other). Mac users are graced by an OS that actually uses the Option (Alt) key on every letter to do something useful. You can type all manner of diacritics and such without using a non-standard layout! It works great for English, German, Swedish, Spanish, French, and perhaps more.
I only wish there was good support for it on Linux and Windows. I will eventually contribute a patch to xkb to fix its version of this.
I only wish there was good support for it on Linux and Windows. I will eventually contribute a patch to xkb to fix its version of this.
I'm no longer using Macs for work, but while the option key does enable useful stuff, you can do even better with Karabiner elements and a Compose key there as well :)
I like to use the qwerty US international. Far better than the Azerty layout which is indeed completely awful.
I do too on Linux, but on Windows that appears to deadkey everything, even apostrophes
On Windows you can install a custom keyboard layout like https://github.com/umanovskis/win-kbd-usint-nodead/
Which azerty? French or Belgian? I find the Belgian one is actually very well suited to programming, with easy access to all common symbols. I can't speak to the French one, but from a quick search it does look insupportable.
I've only used the French one (for about 5 years, while living in France... it was awful)
Yeah US layout + Compose key is also my setup.
Dead keys are particularly fun, as it takes two key presses to produce a result. Accessibility of keyboards/layout could indeed be improved. I switched to custom US layout, because of too many issues with a non-US layout. My custom layout uses AltGr combinations to add a few local characters. It is a bit clumsy, but at least keyboard shortcuts work most of the time.
I have done the same, on my work laptop I specifically asked for it to come with US layout.
Honestly don't wait on all the web Dev to fix their app. Buy yourself a programmable keyboard that tells the computer they are a "normal US layout keyboard".
Now when you press "shift+7" on your keyboard it only sends "regular US keycode for /"
As a benefit you'll maybe also realize that Azerty or Qwertz are pretty bad layout for typing French/German, and you'll come up with something better.
Now when you press "shift+7" on your keyboard it only sends "regular US keycode for /"
As a benefit you'll maybe also realize that Azerty or Qwertz are pretty bad layout for typing French/German, and you'll come up with something better.
If you do that you'll break anything that maps based on scancodes in order to have a consisten physical locations while the key label does not matter, like games with WASD for movement and nearby keys for shortcuts.
> For example if you have / as you shortcut for focusing the search field because your US users are accustomed to this behavior, just add alt+s as an alternative for international users.
And Alt+S already opens the browser's History menu, on Firefox, and I'm not sure that applications can override this binding, or if users will appreciate it.
----
Last year, I was working on a Qt app that needed to translate physical scancodes (not layout-dependent character codes) located in a piano layout, into music notes. I developed a library (https://github.com/nyanpasu64/qkeycode/) and submitted several Qt/QtWebEngine bugfixes.
Anyway, fuck KeyboardEvent.keyCode. It differs across OSes and browsers.
Fun fact: On QWERTY, + requires holding Shift. Some apps (Qt Creator, QtWebEngine) don't zoom in upon Ctrl-=, but only Ctrl-Shift-+. IIRC Firefox in English locales binds both Ctrl-+ and Ctrl-= to "zoom in"
And Alt+S already opens the browser's History menu, on Firefox, and I'm not sure that applications can override this binding, or if users will appreciate it.
----
Last year, I was working on a Qt app that needed to translate physical scancodes (not layout-dependent character codes) located in a piano layout, into music notes. I developed a library (https://github.com/nyanpasu64/qkeycode/) and submitted several Qt/QtWebEngine bugfixes.
Anyway, fuck KeyboardEvent.keyCode. It differs across OSes and browsers.
Fun fact: On QWERTY, + requires holding Shift. Some apps (Qt Creator, QtWebEngine) don't zoom in upon Ctrl-=, but only Ctrl-Shift-+. IIRC Firefox in English locales binds both Ctrl-+ and Ctrl-= to "zoom in"
Uhg, the keyboard zoom shortcut drives me bonkers sometimes. Most apps can't seem to make up their mind, or be bothered to implement both.
I'm french canadian and the most satisfying solution I've found is to keep switching from one keyboard layout to another. I mostly use the american layout when I code, and the french canadian one to communicate. I got used to it in about a week.
Not sure it's comforting but after exposure to french and swiss keyboard layouts, the canadian one is for me a sweet spot. It's "almost standard qwerty" while allowing to write in french properly. "US International with dead keys" is workable but somehow weirder and less consistent between OSX and Linux.
I now exclusively use US-International No Dead Keys. I just use the right alt key + qpys to get äöüß. I hate having to switch layouts and switching layouts accidentally while typing. Those key combinations are not worse than []{}\ on the german layout.
I use a US keyboard with Caps Lock mapped to Compose (using WinCompose [0]), which lets me type any Unicode character I need. Totally agree that switching layouts is a pain.
[0] https://github.com/samhocevar/wincompose
[0] https://github.com/samhocevar/wincompose
Looking at that layout, it's almost US-ANSI. Doesn't look so bad for programming.
The root of the problem is what this article correctly describes as the deprecated properties `keyCode` et al. These are essential raw Windows events that browsers in the '90s unwisely decided to expose. For any platform that is not Windows, these have to be emulated, which is not at all simple, since the details vary according to particular Windows keyboard layouts.
It's not a windows thing. These are the codes that the hardware uses, on all platforms.
Nope. They're Windows ‘virtual key codes’, which are entirely unrelated to Windows ‘scan codes’, which are also not hardware codes (but are distantly descended from the original IBM PC).
For instance, consider ‘/’ (beside right shift). The normal hardware code (USB HID) is page 7 usage 0x38 (sometimes written 0x070038; in theory HID usage codes can exceed 16 bits, but in practice they don't). The PS/2 hardware code (for old keyboards) is 0x4A. The Windows ‘scan code’ is 0x35. And finally, the browser legacy ‘keyCode’ which you can see at https://w3c.github.io/uievents/tools/key-event-viewer.html is 191 (0xBF), which is the Windows virtual key ‘VK_OEM_2’.
For instance, consider ‘/’ (beside right shift). The normal hardware code (USB HID) is page 7 usage 0x38 (sometimes written 0x070038; in theory HID usage codes can exceed 16 bits, but in practice they don't). The PS/2 hardware code (for old keyboards) is 0x4A. The Windows ‘scan code’ is 0x35. And finally, the browser legacy ‘keyCode’ which you can see at https://w3c.github.io/uievents/tools/key-event-viewer.html is 191 (0xBF), which is the Windows virtual key ‘VK_OEM_2’.
Thanks for the info, I wasn't aware. I thought it was all 'scancodes'
In order to write backtick, I have to shift-click the key left to backspace and then click spacebar.
Tilde ~ is similar: option-click and then space.
This makes the out-of-the-box keyboard shortcut for switching window on macOS unreachable on my macbook pro.
There are several default shortcuts on osx that are unreachable from international keyboards.
Tilde ~ is similar: option-click and then space.
This makes the out-of-the-box keyboard shortcut for switching window on macOS unreachable on my macbook pro.
There are several default shortcuts on osx that are unreachable from international keyboards.
Perhaps you can remap tilde to some other key on the keyboard?
It really surprised and disappointed me recently that native macOS apps have the same problem outlined here. For example, the standard system-wide ‘back’ shortcut (e.g. in Safari, Finder, Preview) is Cmd+[, but this is inoperable in many keyboard layouts that don’t have any key that produces [ without modifiers.
(For context: I was writing a simple mouse gestures utility that sends that keyboard shortcut to accomplish backward navigation for an appropriate gesture, but discovered this to be unreliable across keyboard layouts).
(For context: I was writing a simple mouse gestures utility that sends that keyboard shortcut to accomplish backward navigation for an appropriate gesture, but discovered this to be unreliable across keyboard layouts).
It‘s even worse on ISO keyboards (the ones with the large return key).
There‘s a physically different key arrangement on these, so even when switching to the US lay-out, some important system-wide shortcuts are still impossible to type (most notably the one for „switch to different window“).
There‘s a physically different key arrangement on these, so even when switching to the US lay-out, some important system-wide shortcuts are still impossible to type (most notably the one for „switch to different window“).
Yeah Apple doesn't seem to even try to cater to non-US users with their shortcuts. That's the first I've heard of a system-wide back shortcut. You can't type that in my layout. The default switch between windows of a single app shortcut is also impossible, IIRC. One that I always have to reconfigure when I switch editors is the line comment shortcut which defaults usually to something like cmd-/.
I wonder if it's any better on iOS or are you just completely out of luck there when you can't reconfigure the shortcuts?
I wonder if it's any better on iOS or are you just completely out of luck there when you can't reconfigure the shortcuts?
[deleted]
One favourite of mine in this genre is applications who use both command-[ and option-command-[. On a Swedish mac keyboard, [ is on option-8, so it is impossible to type just command-[ without the option key...
This article looks at non-US but missed non-Latin where things gets worse.
Arabic, Chinese, Hebrew, Russian among others.
When set to different layout many apps ignore common actions like Cmd/Ctrl + C and you need to make sure you're using a latin layout.
Arabic, Chinese, Hebrew, Russian among others.
When set to different layout many apps ignore common actions like Cmd/Ctrl + C and you need to make sure you're using a latin layout.
One of many reasons i switched from a Euro ISO layout to a QWERTY ANSI layout a while ago. It took me about 3 weeks to get comfortable with QWERTY ANSI, plus another 2 months to fully get back to my regular typing speed. 100% worth it tho if you need a bunch of special characters as you regularly do with most programming languages.
Some tips:
- switch out ALL you keyboards, at home, at work, on all devices - use EurKey* for reaching special keys in your language (french, german, whatever...)
* https://eurkey.steffen.bruentjen.eu
Some tips:
- switch out ALL you keyboards, at home, at work, on all devices - use EurKey* for reaching special keys in your language (french, german, whatever...)
* https://eurkey.steffen.bruentjen.eu
What kind of bothers me is that while many accented letters are available just by pressing AltGr/ShiftAltGr/etc, common Slavic ones (č, š, ž...) aren't. You have to use dead keys to type them, which defeats the purpose. You can already type them in a similar way on macOS by just holding down the original letter on a Mac Canadian/Australian/EngIntl layout, but that's a pain for pretty much anyone who types a lot. These letters are used often enough to have their own keys on many localized keyboard layouts.
You can use other software to remap the keys to your liking, for example MSKLC on Windows.
How did you cope with the horizontal enter key? That is the single most unpleasant thing whenever forced on ANSI. (I'm not a touch typist)
I also switched to ANSI (with a custom software layout) after using ISO for most of my life. I prefer the wider/horizontal Enter key on ANSI. I'd sometimes accidentally hit the key above it (\), but over time it got better and now it's not a problem anymore.
So what to do about mnemonics? What about keyboard placement?
> This means when the key combination is alt+/, the shortcut should be triggered when a german layout user presses alt+shift+7.
Really? The / is conveniently accessible on a US layout; shift+7 isn't. So this gains you the benefit that you don't have to change documentation (it is "/" however you type it), but much less usable on other layouts. Alternatively, you could try to use the key in the same physical position, but - is already used for other shortcuts due to its meaning.
> This means when the key combination is alt+/, the shortcut should be triggered when a german layout user presses alt+shift+7.
Really? The / is conveniently accessible on a US layout; shift+7 isn't. So this gains you the benefit that you don't have to change documentation (it is "/" however you type it), but much less usable on other layouts. Alternatively, you could try to use the key in the same physical position, but - is already used for other shortcuts due to its meaning.
For Western European devs: do try the "USA International (AltGr dead keys)" layout.
It's great for programming and quite good for all the Western European languages (maybe not so much for Eastern European languages that are more creative with diacritics).
I wish I'd known about it before spending a lot of time creating my own custom layout for Linux and Windows, although since I went through the trouble that's what I still use.
It's great for programming and quite good for all the Western European languages (maybe not so much for Eastern European languages that are more creative with diacritics).
I wish I'd known about it before spending a lot of time creating my own custom layout for Linux and Windows, although since I went through the trouble that's what I still use.
I don't know which language you're using but for french I migrated from "US International with dead keys" to "canadian english". I fill that, among other things, simple quotes are easier to type and consistency between OSX and Linux is better. A matter of habits and workload balance I guess.
You are talking about a different layout, which I also dislike.
I'm talking about "AltGr dead keys", in which the quotes are available directly and the accents are entered using e.g. AltGr-'.
I'm using 6 european languages occasionally, of which 3 every day, including French. Of these, Canadian English would be only useful for French (e.g. it does not have a tilde dead key AFAIK) and is still different enough from US to be annoying for programming (e.g. the angle brackets are in the "wrong place"). Certainly a big upgrade from AZERTY though!
EDIT: My remark on the Canadian English layout above is based on the first layout that showed up when I googled it, but now I noticed that a lot of different variants come up in the search and I don't know which one you're using. In any event, they all seem to be weaker either for programming or for non-FR/EN languages or both.
I'm talking about "AltGr dead keys", in which the quotes are available directly and the accents are entered using e.g. AltGr-'.
I'm using 6 european languages occasionally, of which 3 every day, including French. Of these, Canadian English would be only useful for French (e.g. it does not have a tilde dead key AFAIK) and is still different enough from US to be annoying for programming (e.g. the angle brackets are in the "wrong place"). Certainly a big upgrade from AZERTY though!
EDIT: My remark on the Canadian English layout above is based on the first layout that showed up when I googled it, but now I noticed that a lot of different variants come up in the search and I don't know which one you're using. In any event, they all seem to be weaker either for programming or for non-FR/EN languages or both.
I can't find any "AltGr dead keys" variant on the OSX I'm using at the moment, I'll check later on Linux. I don't have any keyboard with a key marked "AltGr" either btw :).
However, the canadian english variant I'm using definitely has a ~ key and accepts alt+n for ñ. Concerning angle brackets they are at the same position as on a standard US layout.
I assume that we are using different operating systems and that they use the same name for different layouts.
However, the canadian english variant I'm using definitely has a ~ key and accepts alt+n for ñ. Concerning angle brackets they are at the same position as on a standard US layout.
I assume that we are using different operating systems and that they use the same name for different layouts.
> can't find any "AltGr dead keys" variant on the OSX I'm using at the moment
I don't use OSX, sorry. Maybe try https://github.com/xv0x7c0/osx-us-altgr-intl
> I don't have any keyboard with a key marked "AltGr" either btw :).
That's the right alt (not to be confused with the alt right).
> the canadian english variant I'm using definitely has a ~ key
Can you type "ã" or "õ"?
I'm not saying it's the optimal solution, in fact my custom layout works slightly better for myself. However, learning how to build that custom layout in both Linux and Windows took me time that would have been better spent elsewhere.
All I'm saying is that people in the same situation I was in (programmer writing daily in multiple Western European languages), this obscure-niche-that-nobody-seems-to-know-about layout will serve you fine 100% of the times, whatever the language, without you spending ungodly hours coming up with your own.
I don't use OSX, sorry. Maybe try https://github.com/xv0x7c0/osx-us-altgr-intl
> I don't have any keyboard with a key marked "AltGr" either btw :).
That's the right alt (not to be confused with the alt right).
> the canadian english variant I'm using definitely has a ~ key
Can you type "ã" or "õ"?
I'm not saying it's the optimal solution, in fact my custom layout works slightly better for myself. However, learning how to build that custom layout in both Linux and Windows took me time that would have been better spent elsewhere.
All I'm saying is that people in the same situation I was in (programmer writing daily in multiple Western European languages), this obscure-niche-that-nobody-seems-to-know-about layout will serve you fine 100% of the times, whatever the language, without you spending ungodly hours coming up with your own.
> That's the right alt (not to be confused with the alt right).
I laughed, thanks for that.
> Can you type "ã" or "õ"?
on OSX' Canadian English yes, AltGr+n followed by a/o.
On the other hand, after paying closer attention to the behavior of the layout with the same name on Linux, there are annoying discrepancies and "English (intl. with AltGr dead keys)" is indeed pretty nice for me too. Thanks for the pointer, I may adopt it too.
I laughed, thanks for that.
> Can you type "ã" or "õ"?
on OSX' Canadian English yes, AltGr+n followed by a/o.
On the other hand, after paying closer attention to the behavior of the layout with the same name on Linux, there are annoying discrepancies and "English (intl. with AltGr dead keys)" is indeed pretty nice for me too. Thanks for the pointer, I may adopt it too.
It totally f—ks up handling of quotes though. I just cannot stand it, personally.
These days, on Windows, I use the Colemak layout, which has a alt-` meta-combo to type common accented letters - I assign that to caps-lock+A with AutoHotKey, and “Bob est ton oncle”.
These days, on Windows, I use the Colemak layout, which has a alt-` meta-combo to type common accented letters - I assign that to caps-lock+A with AutoHotKey, and “Bob est ton oncle”.
I believe you are talking about a different layout, "US International with dead keys".
I'm talking about "AltGr dead keys", in which the quotes are available directly and the accents are entered using e.g. AltGr-'.
It's not available out of the box in Windows but you can easily find ready to install layouts online.
I'm talking about "AltGr dead keys", in which the quotes are available directly and the accents are entered using e.g. AltGr-'.
It's not available out of the box in Windows but you can easily find ready to install layouts online.
Hah, yes, I’ve had lots of problems with keyboard layouts. I have a hobby requiring lots of unusual characters (e.g. ɛɔþʔəɬɑʒ), and I haven’t yet found a keyboard layout which allowed me to type all these characters with absolutely no problems. I started off using the Canadian Multilingual Standard [0], which worked well enough, but uses Ctrl rather than AltGr as a modifier, with all the conflicts that entails. Also, some frequent characters such as []/ were hard to get to, and I never did manage to retrain my muscle memory to get used to their positioning. I eventually switched to the Finnish Multilingual layout [1], which fixed the Ctrl problem but not my muscle memory. I think I used Keyman [2] for a while, but I don’t remember it working very well. At the moment, I’m using my own custom keyboard layout [3], which generally seems to work very well… except in Microsoft applications, which seem to inconsistently not recognise dead keys with AltGr. (Excel is a particular offender, which is particularly horrible since I often need to type characters like λση⁻¹ in it.) Not that they’re alone: out of the major GUI libraries I tested recently, only Qt and Electron worked correctly. Clearly, this is an area in need of improvement.
[0] https://en.wikipedia.org/wiki/CSA_keyboard
[1] https://en.wikipedia.org/wiki/AltGr_key#Finnish_multilingual
[2] https://keyman.com/
[3] https://github.com/bradrn/Conkey
[0] https://en.wikipedia.org/wiki/CSA_keyboard
[1] https://en.wikipedia.org/wiki/AltGr_key#Finnish_multilingual
[2] https://keyman.com/
[3] https://github.com/bradrn/Conkey
Another problem on international keyboards besides unexpected key-codes for symbols is that it is awkward to type them with extra AktGr or Shift. Even with Vi-based editors this an awkward problem.
So indeed avoid symbols. If the application needs more shortcuts, then use prefix keys for less frequently used shortcuts or allow the user to type commands.
So indeed avoid symbols. If the application needs more shortcuts, then use prefix keys for less frequently used shortcuts or allow the user to type commands.
They had me until:
> This means when the key combination is alt+/, the shortcut should be triggered when a german layout user presses alt+shift+7.
No way. I want to press alt+dash, which is in the same place as alt+/ on a US keyboard. Pressing alt+shift+7 is the equivalent of Lee-Harvey-Oswald-grade marksmanship on a keyboard.
> This means when the key combination is alt+/, the shortcut should be triggered when a german layout user presses alt+shift+7.
No way. I want to press alt+dash, which is in the same place as alt+/ on a US keyboard. Pressing alt+shift+7 is the equivalent of Lee-Harvey-Oswald-grade marksmanship on a keyboard.
The problem is, most people will not know that alt+dash is an alternative for alt+/ with their layout. Also, it does not actually work with all browsers and operating systems. Try to use dash as a replacement for / in Firefox and you will be disappointed.
However, developers defining and documenting alt+/ as an alternative for alt+/ when registering the binding would indeed be a fine solution.
However, developers defining and documenting alt+/ as an alternative for alt+/ when registering the binding would indeed be a fine solution.
I actually made a custom MacOS Croatian keyboard layout to work around these issues.
It switches to a US layout if ctrl/lalt/cmd are pressed, including switching `Z` and `Y`:
https://github.com/ivancuric/mac-hr-sane-layout
MacOS is notoriously bad for handling international shortcuts. Eg, `Cmd+[` is back system-wide. To get [ on my keyboard I need to press `AltGr + F`. `Cmd + AltGr + F` doesn't work, of course.
Where the `[` character is on a US keyboard, I have `Š`. `Cmd + Š` also doesn't work. Manually recording a shortcut to rebind it to `Cmd + Š` also used to output `Cmd + Ctrl + Alt + F`, which seems to be fixed at some point in the last 3 years.
It switches to a US layout if ctrl/lalt/cmd are pressed, including switching `Z` and `Y`:
https://github.com/ivancuric/mac-hr-sane-layout
MacOS is notoriously bad for handling international shortcuts. Eg, `Cmd+[` is back system-wide. To get [ on my keyboard I need to press `AltGr + F`. `Cmd + AltGr + F` doesn't work, of course.
Where the `[` character is on a US keyboard, I have `Š`. `Cmd + Š` also doesn't work. Manually recording a shortcut to rebind it to `Cmd + Š` also used to output `Cmd + Ctrl + Alt + F`, which seems to be fixed at some point in the last 3 years.
I raise you to MacOS + browser + Citrix + Linux + Other browser with Linux being a farm with different keyboard configurations so you never know what you face when you try to log in (requiring the '@' sign).
"Do you use an international keyboard layout?"
No, I use a national (UK) one.
No, I use a national (UK) one.
Also while we're at it...fix this for bitlocker. Makes special characters in passwords a nightmare and you need to memorize where that stupid character is...
It’s unwise anyway to use letters outside of a-Z0-9 in a password unless absolutely necessary
It's also unwise to use a password, when you should be using a passphrase[0]. See eg https://www.explainxkcd.com/wiki/index.php/936.
Edit: 0: or at least a pass-multiple-words, depending on how picky your definition of "phrase" is about grammer. It shouldn't be "word", singular, is the point.
Edit: 0: or at least a pass-multiple-words, depending on how picky your definition of "phrase" is about grammer. It shouldn't be "word", singular, is the point.
KeyCombiner looks very interesting.
I once worked on a keyboard visualizer for vscode (https://hediet.github.io/visual-keyboard), but I was never really happy with it.
It would be nice if keyboard shortcuts were a matter of the OS and applications would expose a list of all available commands with default shortcuts...
It would be nice if keyboard shortcuts were a matter of the OS and applications would expose a list of all available commands with default shortcuts...
That's why I switched from a German QWERTZ layout to US International.
Don't like the dead keys, but the shortcut confusion is worse.
Don't like the dead keys, but the shortcut confusion is worse.
The best solution would be to actually allow users to change the keyboard shortcuts on the software they use.
Absolutely, that would be a fine solution. It is also mentioned in the article. I really don't know why web application developers are not doing it. Especially when you could be the first to do it and have a real edge over your competitors.
And then you discover non-ASCII world...
I am using a French azerty keyboard, but since '[]' and '{}' are in wierd locations,i always remap them to US-alike. This breaks the diacritics, but oh well
I also like my ';' and '.' swapped, because dot is clearly more useful when typing in terminal
I also like my ';' and '.' swapped, because dot is clearly more useful when typing in terminal
The fix is to buy US keyboards and configure a compose key for non-a-z characters.
> Some US users might welcome this change as well, because alt+s can be typed with just the left hand while / reqiures people to take their hand of the mouse
Only an issue when your mouse on the right side of the keyboard
Only an issue when your mouse on the right side of the keyboard
This is one thing that bothers me in Emacs. The shortcuts are not consistent between modes. It's a lot of mental overhead if you go with a config close to the defaults.
The author spends a lot of time explaining the APIs that have been deprecated but doesn’t say which one is the correct one to use now...
They do briefly mention it, `key`
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
Unfortunately, it's not that simple. For different apps, different approaches might be best. That's why there is a section on possible solutions.
Regarding events, attributes, and deprecation: keydown (event), code (attribute), and key (attribute) are not deprecated.
Regarding events, attributes, and deprecation: keydown (event), code (attribute), and key (attribute) are not deprecated.
Most prominent for me: ctrl+z on a german keyboard. You have to stretch your hand a lot.
[deleted]
Slack, please read this. Thank you.
I use an English keyboard for development.
Yeah I do the same, for these same reasons. It's just so much faster to type [] {} and so on vs the Finnish layout.
Windows for backwards compatibility reports 'right-alt' as 'alt+control'.
Many applications developers assign key combos with no negative checks. So 'ctrl-s', typically used for save gets triggered when user wants to type 'ś'. To repeat, "right-alt"+"s" is reported as "alt"+"control"+"s", which triggers crappy "control"+"s" checks.
Similar scenarios happen many places that check for 'alt'+'letter' without checking if control also is not pressed.
Microsoft thread for team user voice issues on this https://microsoftteams.uservoice.com/forums/555103-public/su...
or Medium's developer talking about 'ś' and 'ctrl'+'s'. https://medium.engineering/the-curious-case-of-disappearing-...