View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001630||OpenMPT||User Interface||public||2022-09-09 05:51||2022-09-27 13:24|
|Reporter||alison||Assigned To||Saga Musix|
|Product Version||OpenMPT 1.30.05.00 / libopenmpt 0.6.4 (upgrade first)|
|Target Version||OpenMPT 1.30.08.00 / libopenmpt 0.6.6 (upgrade first)||Fixed in Version||OpenMPT 1.30.08.00 / libopenmpt 0.6.6 (upgrade first)|
|Summary||0001630: restore key should restore from defaults|
Right now when hitting Restore button in the Keyboard tab of OpenMPT Setup, it restores the currently-highlighted key to the previous value immediately before you changed it in the Key field. But if you save your changes and then reopen the Keyboard tab, Restore does nothing.
I would like to be able to a restore a particular key binding that i rebound at some point in the past to the default. I might be missing something, but it seems like right now you need to export your own mappings, then restore the default configuration, then see what the original binding was, then reimport your own mappings, then set that binding back to the default. I think it would be more helpful if the Restore button provided a way to do this, perhaps if you clicked it on a key where you hadn't changed anything since the last apply/save.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?|
|Tested code revision (in case you know it)|
Note that with the current version of OpenMPT (1.30), it is possible to restore a default keybinding by deleting the custom keybinding and then restarting OpenMPT (or by saving the keybindings and immediately loading them again). And of course there is the even less elegant solution of looking up the default keys in the manual.
This auto-restore mechanism often lead to a lot of confusion though, so starting from OpenMPT 1.31 only newly added default keybindings will be added to custom keymaps after updating OpenMPT to a new version, so either way a solution to this issue has to be found. I'm not sure how useful the current behaviour of the Restore button is - if you made a mistake, you could also cancel and reopen the settings dialog, although that is also rather cumbersome, in particular if you made a lot of changes without hitting the Apply button.
A dual-function Restore button (first click: restore to previously used key, second click: restore to defaults) could help, but one think to keep in mind is that Restore works on a per-choice basis: If there are three different keybindings assigned to a shortcut, Restore only resets the currently selected one. I'm not sure if the "restore to default" behaviour is very sensible in that situation: Should it only restore the, say, second choice, if that's what was currently selected? What if there are now three bindings but the default map only had one: What happens if you hit restore on the second or third choice? What happens if the first default choice for a shortcut was Ctrl+X and the second choice was Ctrl+Y, but the custom keybindings were changed to the first choice being Ctrl+Y and the second being Ctrl+X?
I saw that ticket about removing the auto-restore option, and was glad to see it's resolved in 1.31 because that's a bit annoying too! Personally I don't mind that the key comes back per se since the main reason I unbind keys is to have a clean and understandable config file (I keep it backed up in source control), but it also is a source of surprise when you accidentally hit a key you thought you had unbound and it does something. (i.e. opposite of principle of least surprise)
You have a point about the potential for added confusion around the Restore button in a possible future state where it also restored defaults. I think the least confusing solution would be for it to only restore the default binding(s) if and only if all other bindings had been deleted for that action. This would essentially be the same behavior that you get right now if you unbind something and then restart the app and magically it's bound again, except now it would be user-controlled on a per-action basis.
Test builds should be available in a few hours from https://builds.openmpt.org/builds/
Gave the test build a run, looks good. Thanks!
|2022-09-09 05:51||alison||New Issue|
|2022-09-10 14:22||Saga Musix||Note Added: 0005306|
|2022-09-11 06:56||alison||Note Added: 0005307|
|2022-09-25 16:53||Saga Musix||Assigned To||=> Saga Musix|
|2022-09-25 16:53||Saga Musix||Status||new => assigned|
|2022-09-25 16:53||Saga Musix||Target Version||=> OpenMPT 1.31.01.00 / libopenmpt 0.7.0 (upgrade first)|
|2022-09-25 16:56||Saga Musix||Note Added: 0005320|
|2022-09-25 16:56||Saga Musix||Target Version||OpenMPT 1.31.01.00 / libopenmpt 0.7.0 (upgrade first) => OpenMPT 1.30.08.00 / libopenmpt 0.6.6 (upgrade first)|
|2022-09-25 16:57||Saga Musix||Status||assigned => feedback|
|2022-09-27 13:19||alison||Note Added: 0005322|
|2022-09-27 13:19||alison||Status||feedback => assigned|
|2022-09-27 13:24||Saga Musix||Status||assigned => resolved|
|2022-09-27 13:24||Saga Musix||Resolution||open => fixed|
|2022-09-27 13:24||Saga Musix||Fixed in Version||=> OpenMPT 1.30.08.00 / libopenmpt 0.6.6 (upgrade first)|