TASEmulators
Update/add more default input mappings
This suggestion comes from the discussion in #3842.
The default controller mappings in general aren't updated often, so that might be doable here.
An especially glaring issue is that cores for computer systems (C64, ZX Spectrum, MSX, etc) lack default mappings for their keyboards. It would be a good idea to create sensible defaults for these, along with updating the rest of the mappings.
I was sure I included default mappings for ZXS. Looks like they were all removed to fix this (or another) issue: https://github.com/TASEmulators/BizHawk/commit/ec3a23259cf0f9528aef661b9df51846997485f4
If the key priority thing is now properly fixed, someone should be able to add the defaults back in maybe?
Ah, I was looking for https://github.com/TASEmulators/BizHawk/issues/3257#issuecomment-1786291002. To summarise my opinions:
- I think we shouldn't have any default hotkey keybinds which are just a single key. (Maybe some standard things like F1, Alt alone, or Pause.) But I don't think it's a good idea to change those unless it's as part of a complete overhaul of the defaults.
- edit 2025-09: The case against single-key binds is simply that it's too easy to accidentally trigger a hotkey (either by hitting the wrong key, or by beginning to type while the wrong window is focused) which then takes more effort to undo than it took to do. Save and load state are the main ones (see #2175).
- If the hotkey priority isn't set to
InputPriority.INPUTand you have a virtual Shift or Ctrl key bound to Shift or Ctrl, the number of hotkey actions you could accidentally trigger is much higher.
- If the hotkey priority isn't set to
- edit 2025-09: The case against single-key binds is simply that it's too easy to accidentally trigger a hotkey (either by hitting the wrong key, or by beginning to type while the wrong window is focused) which then takes more effort to undo than it took to do. Save and load state are the main ones (see #2175).
- Similarly, I think mapping most of the host keyboard to the virtual keyboard is a bad out-of-the-box experience. If only because the default keybinds must not have conflicts. I still wouldn't like it if all the hotkeys used modifiers though.
- Earlier, I suggested we could have some sort of preset to populate the keyboard binds for those who wanted that immersive experience. See also #1636.
- Modifier keys are inherently different: If one is mapped to a virtual key (as was the default for C64 before the above commit), trying to input e.g. Shift+R on the virtual keyboard may instead trigger another binding (e.g. the Rewind hotkey). Thankfully we don't seem to have any virtual buttons bound to Ctrl or Shift for any system at the moment.
- Perhaps if a modifier key alone is bound to anything, a message should appear at the bottom the keybinds dialog explaining how to use the bind priority toggle?
Similarly, I think mapping most of the host keyboard to the virtual keyboard is a bad out-of-the-box experience. If only because the default keybinds must not have conflicts.
We have a priority button exactly for those conflicts. If the goal is not ever having to use that button, then the replacement system should have been implemented first, before removing all keyboard bindings.
As I said there, having to rebind every key for every release is a worse experience.
I wasn't aware of #3257 or ec3a23259cf0f9528aef661b9df51846997485f4 and now that I do I really don't understand the resolution.
How is a normal user expected to interact with virtual keyboard controllers, if not by mapping each of the virtual keys to a real key? Removing all default keybindings because some of them conflict with default hotkey keybindings is nonsensical imo. Why not remove all default hotkey bindings instead at that point?
We have a priority button exactly for those conflicts.
This. This problem of conflicts between hotkey and key bindings is already resolved in bizhawk through the priority system, and if this setting is somehow not adequate or not communicated clearly enough then that should be fixed, and not default bindings removed.
As groundwork for a one-click populate keybinds feature, I was thinking it might be good to group the virtual keyboard keys somehow inside the ControllerDefinition object, which cores would set by using a new AddKeyboard(this ControllerDefinition def, string[][] rows) extension method similar to AddXYPair. (I'd choose a list of lists so that maybe it could also be used to eliminate or at least reduce the amount of boilerplate in virtual pad schemata for keyboards.) The keybinds dialog would then show a button if the metadata is present, and clicking the button would read from a new DefaultControls prop (somehow; it's currently instantiated in the Config ctor and then falls out of scope without being stored).
OK let's read!
I think we shouldn't have any default hotkey keybinds which are just a single key.
That's an insane take. We want to meet users habits when they switch to hawk after several decades of using other rerecording emulators. We want the switch to be smooth, unlike lsnes which goes against all prior habits (in a few cases that's good, but most of the time it's not). And if someone doesn't have a prior habit of how rerecording emulators work, then we just need to make it easy for them to adapt for common practices. And then some of those practices may be changed, after a lot of discussion with actual users and other devs.
Maybe some standard things like F1, Alt alone, or Pause.
What's the full list of things you consider standard? Most of our hotkeys have all been there for long enough to be considered standard in their own right.
But I don't think it's a good idea to change those unless it's as part of a complete overhaul of the defaults.
I don't understand what you're saying there. Of course we don't want common hotkeys to suddenly change to something counter-intuitive.
The case against single-key binds is simply that it's too easy to accidentally trigger a hotkey (either by hitting the wrong key, or by beginning to type while the wrong window is focused) which then takes more effort to undo than it took to do. Save and load state are the main ones
It's impossible to protect against something accidental. Unless we notice a clear pattern and add baka-yoke. Removing normal functionality just to avoid rare accidents is not an improvement.
If the hotkey priority isn't set to InputPriority.INPUT and you have a virtual Shift or Ctrl key bound to Shift or Ctrl, the number of hotkey actions you could accidentally trigger is much higher.
Power users who want to comfortably use emulated keyboard and hotkeys, will have to either buy a bigger keyboard or learn the discipline and switch priorities as needed, OR they just rebind the few keys they have problems with.
Similarly, I think mapping most of the host keyboard to the virtual keyboard is a bad out-of-the-box experience.
It's bad the way retroarch does it, where it just randomly mixes everything together and I don't remember it having a way to switch priorities (because it's impossible to find something in its menus anyway). Bad user experience is forcing people to bind everything every release. As I said in 80e903f9494b6a3e6c6f9a566964e7bab120bfdd
Cores must be usable out of the box, first and foremost for casual play. Sure we're a TASing emulator, but we're also a casual gaming emulator. A rather popular at that, and we want the experience to be much nicer than other multisystem emulators that aim at casual gamers. Not requiring any obscure configuration just to be able to run a game is an important part of this.
If only because the default keybinds must not have conflicts.
Conflicts are unavoidable simply because we emulate computers with keyboard. Power users need to learn proper usage.
Earlier, I suggested we could have some sort of preset to populate the keyboard binds for those who wanted that immersive experience.
Switching around different bindings sounds awesome! If someone wants to not have any keys bound they load an empty config. If they want them back they load the other one. Or they create their own and use it across releases. Without forced removal of all default binds for everyone.
Modifier keys are inherently different: If one is mapped to a virtual key (as was the default for C64 before the above commit), trying to input e.g. Shift+R on the virtual keyboard may instead trigger another binding (e.g. the Rewind hotkey). Thankfully we don't seem to have any virtual buttons bound to Ctrl or Shift for any system at the moment.
Already covered.
Perhaps if a modifier key alone is bound to anything, a message should appear at the bottom the keybinds dialog explaining how to use the bind priority toggle?
A warning for those conflicts would be seriously helpful. The user could go and rebind something, or just ignore the warning.
I reverted the commit that removed keyboard binds, this issue can be closed. Improvements to the system, can be discussed separately.
Maybe some standard things like F1, Alt alone, or Pause.
What's the full list of things you consider standard? Most of our hotkeys have all been there for long enough to be considered standard in their own right.
I meant "standard" among graphical Windows apps, not some convention among emulators. Those 3 plus Tab and F11 are all that I can think of. I'd consider things like Ctrl+C, Ctrl+O, or Alt+F4 standard too, but they include a modifier.
But I don't think it's a good idea to change those unless it's as part of a complete overhaul of the defaults.
I don't understand what you're saying there. Of course we don't want common hotkeys to suddenly change to something counter-intuitive.
Something I want to avoid is making a bunch of small changes to the default keybinds (or menubar layout, or how settings are grouped...) across releases. I'm often annoyed when apps like Firefox do that. It's better to start by laying out the problem domain and then design something cohesive and future-proof. Ideally that would then go through a usability study (name?) or at least a public consultation before replacing the old system. Letting users choose between the two can work in some cases, like with keybinds. The key is to make a new design different enough that people don't associate it with the old one and their muscle memory doesn't kick in. That's more relevant to GUI layout redesigns though.
The case against single-key binds is simply that it's too easy to accidentally trigger a hotkey (either by hitting the wrong key, or by beginning to type while the wrong window is focused) which then takes more effort to undo than it took to do. Save and load state are the main ones
It's impossible to protect against something accidental. Unless we notice a clear pattern and add baka-yoke. Removing normal functionality just to avoid rare accidents is not an improvement.
Not impossible then. Software in $CURRENTYEAR has little excuse for not supporting undo on everything. Removing functions/features to avoid rare accidents happens all the time, including in consumer software, mainly for security reasons.
Software in $CURRENTYEAR has little excuse for not supporting undo on everything.
Sounds unrealistic. I doubt anyone would build such a thing for hawk. Tho if someone did, I'd obviously not mind it!
Removing functions/features to avoid rare accidents happens all the time, including in consumer software, mainly for security reasons.
I wasn't trying to say that it must never happen for the entire humanity for any reason whatsoever. I was strictly speaking about the TAS workflow. Even then, if there's a security problem suddenly discovered in invalidating greenzone, you don't solve it by making greenzone invalidation impossible.
I think your commit 80e903f9494b6a3e6c6f9a566964e7bab120bfdd basically fixes this issue as written.
Other discussion about different approaches to keybinds can happen elsewhere, like #1636 or a new PR or a new clearly scoped issue.
