5 ms·

As the maintainer of Wayfire, I would like to say why I don't consider this a critical issue: the current system allows you to bind actions to a particular phys

As the maintainer of Wayfire, I would like to say why I don't consider this a critical issue: the current system allows you to bind actions to a particular physical key. So, no matter what physical keyboard layout and actual layout in software, with the current system, you can bind the action to the desired physical key. Or do people actually want their keybindings to change when they change their layouts?

toastal 3y ago
I edit in Vim using Dvorak. I always expect `ciw` to “change inner word” regardless of layout. Most shortcuts are stored in my head in this way, not by physical key placement. That said, it doesn’t bother me that xmonad sets up my keys based on the default layout, so if I switch to another to type in a non-Latin script, the WMs shortcuts stay bound to my ‘normal’ keymap as the others are only used temporarily.
malermeister 3y ago
> do people actually want their keybindings to change when they change their layouts? As a colemak user, definitely. It's a super weird and confusing experience otherwise and this bug is a blocker for me checking out your (otherwise quite promising-looking) project.
- ammen99 3y ago
  Wait, so you use both colemak and the normal qwerty layout and switch between them on the same keyboard? As a vim user, I am hugely relying on muscle memory - which is why saying that bindings should vary between layouts seems really weird, as that would make muscle memory way less effective. Then again, that is my usage ..
  - malermeister 3y ago
    It's kind of hard to explain, but I think my brain doesn't go "letter -> key on keyboard", it goes "letter -> location in keyboard layout -> key on keyboard". If the key on keyboard stays the same, even though the layout changes, it really messes with the way my brain maps from letters to muscle movements, idk if this makes sense.
codetrotter 3y ago
> do people actually want their keybindings to change when they change their layouts? Personally, yes. If I am in Qwerty and I press the T key, I press the button where T is physically in Qwerty. If I am in Dvorak, I press the button where T is physically in Dvorak. Pressing the button where something is physically in Qwerty when I am in another layout would be very confusing, because effectively it would be that everything else is respecting the layout I am using except this one program that is still using the Qwerty positions of the keys.
hnuser123456 3y ago
Presumably, if one replaced their physical keyboard with one with a different layout, then change the layout to match in software, then the binding would still apply to the same "physical key location"?
- ammen99 3y ago
  Bindings respond to a particular hardware key code. If you have a qwerty keyboard, when you press the key labeled as 'Q', the keyboard sends a `KEY_Q`. If you take a different physical device, `KEY_Q` will probably be reported for the key where `Q` is written on the new keyboard.
  - dasyatidprime 3y ago
    This is contrary to my understanding of mainstream keyboard technology. Scancodes, like what you're looking at with Linux input, mainly refer to physical positions relative to a “standard” keyboard, and the labels in the header file for the alphabetic section are based on assuming the keyboard is QWERTY. A keyboard that comes from the manufacturer with different-layout keycaps on it will still output physical-position-based scancodes, and KEY_Q in the header file is not normally generated by the key that the manufacturer shipped a cap labeled Q on; it's the key in the position that would output Q if it were a QWERTY keyboard. (Though there's a few edge cases around e.g. ANSI vs ISO layout.) This idea is corroborated if you look in the USB HID Usage Tables that the Linux input event codes are based on. From https://usb.org/document-library/hid-usage-tables-14 https://usb.org/document-library/hid-usage-tables-14: > Note: A general note on Usages and languages: Due to the variation of keyboards from language to language, it is not feasible to specify exact key mappings for every language. Where this list is not specific for a key function in a language, the closest equivalent key position should be used, so that a keyboard may be modified for a different language by simply printing different keycaps. One example is the Y key on a North American keyboard. In Germany this is typically Z. Rather than changing the keyboard firmware to put the Z Usage into that place in the descriptor list, the vendor should use the Y Usage on both the North American and German keyboards. This continues to be the existing practice in the industry, in order to minimize the number of changes to the electronics to accommodate other languages. This can get somewhat more complicated when you get into keyboards with custom remapping firmware where they do actually shift the scancodes around, but that creates other potential issues, and users who are doing that basically just have to deal with their own integration tradeoffs. Similar considerations apply to keyboards with non-mainstream physical layouts.
jraph 3y ago
> Or do people actually want their keybindings to change when they change their layouts? That's what actually happens everywhere. For instance undo is usually CTRL+Z. On QWERTY that will be CTRL + the key at the left side of the X, and on AZERTY that will be CTRL+the key at the left side of the E. Therefore, that's the behavior people expect and it has advantages. Having to write KEY_Z to actually have KEY_W is also jarring and very counter-intuitive. That also means UIs don't have to translate key bindings, unless they want them to correspond to some word (for instance word processors have CTRL+B for bold in English, but CTRL+G is allowed in French (Bold = Gras). Now I also understand the benefits of your choice, and I appreciate that nobody is entitled to make you change this in any case. At worse everybody should be thankful for your choice to release this work as open source and spend time on it to the benefit of everyone. I'm also not a user so I don't have any stake in this.
- ammen99 3y ago
  I am mostly trying to understand what people actually use. I hate exactly this thing in most applications: ctrl-z doesn't work when I use the german layout (usually I use qwerty/us), and assumed most people would dislike it as well...
  - jraph 3y ago
    If someone ever does a survey, I'd be interested to read a blog post on this :-) In my case I'm not sure what I prefer. When switching from AZERTY to QWERTY, I'm lost because the keybindings are not the same. Especially that CTRL+Z "becomes" CTRL+W which kills the current tab, and CTRL+W "becomes" CTRL+Q which kills the app. OTOH, I don't usually switch layouts, and like that the configuration file / the UI matches the current layout. I guess the conf could allow setting layout-specific keybindings. It complicates things quite a bit though.
  - 05 3y ago
    One more thing to think about: some layouts don't have Latin letters. So if you switch from English to Ukrainian, you'd lose all your keybindings with the approach requested in the ticket..
  - 3y ago
dasyatidprime 3y ago
As another non-QWERTY user, I usually want desktop keybindings (excluding games) to follow layout changes, because I'm remembering the function by the mnemonic. Most applications have this behavior on my existing FDO/Linux system. On the Windows machine I use sometimes, by contrast, it seems like holding Control effectively forces QWERTY, which has been an unending source of little pains. If I didn't already have the QWERTY keymap memorized and I had to figure out which keys were “actually” which to configure things, it would be a lot harder. But then, I'm an X user still; I'd like to dip into Wayland, but a combination of fragmentation of protocols and the seeming relative “hardness” of the stack in terms of customizability have caused me to hesitate thus far. And maybe that Windows behavior also means that's what you want to mimic for a lot of other people?
- pxc 3y ago
  > because I'm remembering the function by the mnemonic. Perhaps this is also a frequency of use issue— if you're relying on the mnemonic rather than muscle memory, it sounds like a shortcut you don't use very often. Or does muscle memory for you come in at a different layer somehow, where the mapping to key locations is basically automatic and instant but you do still consider key names as you navigate hotkeys?
  - dasyatidprime 3y ago
    The latter and definitely not the former, in my case. As far as I can tell from internal experience, my automatic procedural memory of where to reach for a character, function, or string transforms along with the layout I currently have it “configured” to use, in a rough mirror of how scancode↔keysym mapping can vary on the OS side. I have used a non-QWERTY layout full time for about 18 months now after being in mostly-QWERTY before, so my QWERTY memory has decayed somewhat, but I have past experience switching back and forth at a time scale of hours. If I want the eyedropper tool in GIMP, I reach for the O, and there isn't a separate conscious step of “okay, so that's O, right?”, it's just a single compound action. If it has to be the O in some other layout than the one I'm using, then I have to stop myself and consciously try to remember where it would be. The tools that I don't use as much I do also have to stop and remember, but that's very distinct in feel. I wonder sometimes whether it's relevant that I'm a heavy Emacs user, in which short command gestures often include non-modified keys and are conceptually close to the physically more text-based M-x invocations. Maybe that type of experience (or what other types? Maybe CLI?) creates a different mental map of the distinction or lack thereof between text entry and shortcut keymaps. Emacs on Windows is especially awkward for me as a result of the QWERTY-on-Control behavior, because e.g. C-x C-t and C-x t now involve different positions for the T. Or maybe people who start out on non-QWERTY layouts on Windows specifically are pushed to remember shortcuts by their location early because the keysyms are illogical, and then they continue doing that, but people who stay on QWERTY all the time could go either way? As others have mentioned, this also doesn't happen as much in gaming, where commands are often bound positionally, with WASD motion (GAST motion in my layout…) as a central example. There's still some expected-keysym mnemonic influence in which of multiple candidate keys to bind to a function as one moves away from the central motion cluster. The vi keys mentioned elsewhere are also very positional in nature, but I rarely use vi bindings, and when I do, the nav-cluster keys are usually an accepted alternative… Gosh. With how much has wound up in this thread, I kind of wonder whether there's more serious ergonomics research on this difference in mental modeling now.
mato 3y ago
> Or do people actually want their keybindings to change when they change their layouts? It depends. As a counterpoint to the folks replying "yes", I have for years had Meta-[1..9] bound to "switch to desktop X". I also regularly use US English and Czech/Slovak keyboards. In the X11 days, I never had to think about this, since for whatever reason (I believe technically a bug and/or X11-specific WM behaviour, but I've lost the reference...) Openbox would use the US English layout for its keybindings exclusively. Since I switched to KDE Plasma on Wayland, I constantly get annoyed, every day, as I may have my keyboard set to SK, press what muscle memory says is Meta-[1] and instead I get a funky zoom, since that keystroke translates to Meta-[+] in the SK layout :-(
tmtvl 3y ago
People's brains just work differently. I don't remember "closing Awesome is Mod4 + Shift + the second key from the left on the bottom row", I remember "Mod4 + Shift + Q (for 'quit')" and my fingers know how to find 'Q'. If I change to Qwerty I'd have plenty of applications where the locations of keyboard shortcuts would change (like "Ctrl + C (for 'Copy')") and not having the keyboard shortcut for "close Awesome" change would be disorienting. That said, maybe I'd have an easier time if it were possible to find a physical Dvorak keyboard, but alas: "worse is better". OT: Wayfire is a really cool project and I admire how well it runs, it's real quality software.
taeric 3y ago
I definitely think of keys per my layout, not what is on the cap. I'd expect that to be the norm for touch typists.
skerit 3y ago
> the current system allows you to bind actions to a particular physical key A particular physical key... on a QWERTY keyboard. But we don't have QWERTY keyboards, so having to bind something to KEY_Q when you want it to map to an A is stupid.

toastal 3y ago

I edit in Vim using Dvorak. I always expect `ciw` to “change inner word” regardless of layout. Most shortcuts are stored in my head in this way, not by physical key placement. That said, it doesn’t bother me that xmonad sets up my keys based on the default layout, so if I switch to another to type in a non-Latin script, the WMs shortcuts stay bound to my ‘normal’ keymap as the others are only used temporarily.

malermeister 3y ago

> do people actually want their keybindings to change when they change their layouts? As a colemak user, definitely. It's a super weird and confusing experience otherwise and this bug is a blocker for me checking out your (otherwise quite promising-looking) project.

ammen99 3y ago
Wait, so you use both colemak and the normal qwerty layout and switch between them on the same keyboard? As a vim user, I am hugely relying on muscle memory - which is why saying that bindings should vary between layouts seems really weird, as that would make muscle memory way less effective. Then again, that is my usage ..
- malermeister 3y ago
  It's kind of hard to explain, but I think my brain doesn't go "letter -> key on keyboard", it goes "letter -> location in keyboard layout -> key on keyboard". If the key on keyboard stays the same, even though the layout changes, it really messes with the way my brain maps from letters to muscle movements, idk if this makes sense.

codetrotter 3y ago

> do people actually want their keybindings to change when they change their layouts? Personally, yes. If I am in Qwerty and I press the T key, I press the button where T is physically in Qwerty. If I am in Dvorak, I press the button where T is physically in Dvorak. Pressing the button where something is physically in Qwerty when I am in another layout would be very confusing, because effectively it would be that everything else is respecting the layout I am using except this one program that is still using the Qwerty positions of the keys.

hnuser123456 3y ago

Presumably, if one replaced their physical keyboard with one with a different layout, then change the layout to match in software, then the binding would still apply to the same "physical key location"?

ammen99 3y ago
Bindings respond to a particular hardware key code. If you have a qwerty keyboard, when you press the key labeled as 'Q', the keyboard sends a `KEY_Q`. If you take a different physical device, `KEY_Q` will probably be reported for the key where `Q` is written on the new keyboard.
- dasyatidprime 3y ago
  This is contrary to my understanding of mainstream keyboard technology. Scancodes, like what you're looking at with Linux input, mainly refer to physical positions relative to a “standard” keyboard, and the labels in the header file for the alphabetic section are based on assuming the keyboard is QWERTY. A keyboard that comes from the manufacturer with different-layout keycaps on it will still output physical-position-based scancodes, and KEY_Q in the header file is not normally generated by the key that the manufacturer shipped a cap labeled Q on; it's the key in the position that would output Q if it were a QWERTY keyboard. (Though there's a few edge cases around e.g. ANSI vs ISO layout.) This idea is corroborated if you look in the USB HID Usage Tables that the Linux input event codes are based on. From https://usb.org/document-library/hid-usage-tables-14 https://usb.org/document-library/hid-usage-tables-14: > Note: A general note on Usages and languages: Due to the variation of keyboards from language to language, it is not feasible to specify exact key mappings for every language. Where this list is not specific for a key function in a language, the closest equivalent key position should be used, so that a keyboard may be modified for a different language by simply printing different keycaps. One example is the Y key on a North American keyboard. In Germany this is typically Z. Rather than changing the keyboard firmware to put the Z Usage into that place in the descriptor list, the vendor should use the Y Usage on both the North American and German keyboards. This continues to be the existing practice in the industry, in order to minimize the number of changes to the electronics to accommodate other languages. This can get somewhat more complicated when you get into keyboards with custom remapping firmware where they do actually shift the scancodes around, but that creates other potential issues, and users who are doing that basically just have to deal with their own integration tradeoffs. Similar considerations apply to keyboards with non-mainstream physical layouts.

jraph 3y ago

> Or do people actually want their keybindings to change when they change their layouts? That's what actually happens everywhere. For instance undo is usually CTRL+Z. On QWERTY that will be CTRL + the key at the left side of the X, and on AZERTY that will be CTRL+the key at the left side of the E. Therefore, that's the behavior people expect and it has advantages. Having to write KEY_Z to actually have KEY_W is also jarring and very counter-intuitive. That also means UIs don't have to translate key bindings, unless they want them to correspond to some word (for instance word processors have CTRL+B for bold in English, but CTRL+G is allowed in French (Bold = Gras). Now I also understand the benefits of your choice, and I appreciate that nobody is entitled to make you change this in any case. At worse everybody should be thankful for your choice to release this work as open source and spend time on it to the benefit of everyone. I'm also not a user so I don't have any stake in this.

ammen99 3y ago
I am mostly trying to understand what people actually use. I hate exactly this thing in most applications: ctrl-z doesn't work when I use the german layout (usually I use qwerty/us), and assumed most people would dislike it as well...
- jraph 3y ago
  If someone ever does a survey, I'd be interested to read a blog post on this :-) In my case I'm not sure what I prefer. When switching from AZERTY to QWERTY, I'm lost because the keybindings are not the same. Especially that CTRL+Z "becomes" CTRL+W which kills the current tab, and CTRL+W "becomes" CTRL+Q which kills the app. OTOH, I don't usually switch layouts, and like that the configuration file / the UI matches the current layout. I guess the conf could allow setting layout-specific keybindings. It complicates things quite a bit though.
- 05 3y ago
  One more thing to think about: some layouts don't have Latin letters. So if you switch from English to Ukrainian, you'd lose all your keybindings with the approach requested in the ticket..
- 3y ago

dasyatidprime 3y ago

As another non-QWERTY user, I usually want desktop keybindings (excluding games) to follow layout changes, because I'm remembering the function by the mnemonic. Most applications have this behavior on my existing FDO/Linux system. On the Windows machine I use sometimes, by contrast, it seems like holding Control effectively forces QWERTY, which has been an unending source of little pains. If I didn't already have the QWERTY keymap memorized and I had to figure out which keys were “actually” which to configure things, it would be a lot harder. But then, I'm an X user still; I'd like to dip into Wayland, but a combination of fragmentation of protocols and the seeming relative “hardness” of the stack in terms of customizability have caused me to hesitate thus far. And maybe that Windows behavior also means that's what you want to mimic for a lot of other people?

pxc 3y ago
> because I'm remembering the function by the mnemonic. Perhaps this is also a frequency of use issue— if you're relying on the mnemonic rather than muscle memory, it sounds like a shortcut you don't use very often. Or does muscle memory for you come in at a different layer somehow, where the mapping to key locations is basically automatic and instant but you do still consider key names as you navigate hotkeys?
- dasyatidprime 3y ago
  The latter and definitely not the former, in my case. As far as I can tell from internal experience, my automatic procedural memory of where to reach for a character, function, or string transforms along with the layout I currently have it “configured” to use, in a rough mirror of how scancode↔keysym mapping can vary on the OS side. I have used a non-QWERTY layout full time for about 18 months now after being in mostly-QWERTY before, so my QWERTY memory has decayed somewhat, but I have past experience switching back and forth at a time scale of hours. If I want the eyedropper tool in GIMP, I reach for the O, and there isn't a separate conscious step of “okay, so that's O, right?”, it's just a single compound action. If it has to be the O in some other layout than the one I'm using, then I have to stop myself and consciously try to remember where it would be. The tools that I don't use as much I do also have to stop and remember, but that's very distinct in feel. I wonder sometimes whether it's relevant that I'm a heavy Emacs user, in which short command gestures often include non-modified keys and are conceptually close to the physically more text-based M-x invocations. Maybe that type of experience (or what other types? Maybe CLI?) creates a different mental map of the distinction or lack thereof between text entry and shortcut keymaps. Emacs on Windows is especially awkward for me as a result of the QWERTY-on-Control behavior, because e.g. C-x C-t and C-x t now involve different positions for the T. Or maybe people who start out on non-QWERTY layouts on Windows specifically are pushed to remember shortcuts by their location early because the keysyms are illogical, and then they continue doing that, but people who stay on QWERTY all the time could go either way? As others have mentioned, this also doesn't happen as much in gaming, where commands are often bound positionally, with WASD motion (GAST motion in my layout…) as a central example. There's still some expected-keysym mnemonic influence in which of multiple candidate keys to bind to a function as one moves away from the central motion cluster. The vi keys mentioned elsewhere are also very positional in nature, but I rarely use vi bindings, and when I do, the nav-cluster keys are usually an accepted alternative… Gosh. With how much has wound up in this thread, I kind of wonder whether there's more serious ergonomics research on this difference in mental modeling now.

mato 3y ago

> Or do people actually want their keybindings to change when they change their layouts? It depends. As a counterpoint to the folks replying "yes", I have for years had Meta-[1..9] bound to "switch to desktop X". I also regularly use US English and Czech/Slovak keyboards. In the X11 days, I never had to think about this, since for whatever reason (I believe technically a bug and/or X11-specific WM behaviour, but I've lost the reference...) Openbox would use the US English layout for its keybindings exclusively. Since I switched to KDE Plasma on Wayland, I constantly get annoyed, every day, as I may have my keyboard set to SK, press what muscle memory says is Meta-[1] and instead I get a funky zoom, since that keystroke translates to Meta-[+] in the SK layout :-(

tmtvl 3y ago

People's brains just work differently. I don't remember "closing Awesome is Mod4 + Shift + the second key from the left on the bottom row", I remember "Mod4 + Shift + Q (for 'quit')" and my fingers know how to find 'Q'. If I change to Qwerty I'd have plenty of applications where the locations of keyboard shortcuts would change (like "Ctrl + C (for 'Copy')") and not having the keyboard shortcut for "close Awesome" change would be disorienting. That said, maybe I'd have an easier time if it were possible to find a physical Dvorak keyboard, but alas: "worse is better". OT: Wayfire is a really cool project and I admire how well it runs, it's real quality software.

taeric 3y ago

I definitely think of keys per my layout, not what is on the cap. I'd expect that to be the norm for touch typists.

skerit 3y ago

> the current system allows you to bind actions to a particular physical key A particular physical key... on a QWERTY keyboard. But we don't have QWERTY keyboards, so having to bind something to KEY_Q when you want it to map to an A is stupid.