View Issue Details

IDProjectCategoryView StatusLast Update
0001630OpenMPTUser Interfacepublic2022-09-27 13:24
Reporteralison Assigned ToSaga Musix  
Status resolvedResolutionfixed 
Platformx64OSWindowsOS Version11
Product VersionOpenMPT / libopenmpt 0.6.4 (upgrade first) 
Target VersionOpenMPT / libopenmpt 0.6.6 (upgrade first)Fixed in VersionOpenMPT / libopenmpt 0.6.6 (upgrade first) 
Summary0001630: 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.

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)


Saga Musix

Saga Musix

2022-09-10 14:22

administrator   ~0005306

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?



2022-09-11 06:56

reporter   ~0005307

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.

Saga Musix

Saga Musix

2022-09-25 16:56

administrator   ~0005320

As of r17973, if there are no choices configured, the Restore button now restores the default for the given shortcut. r17974 also backports this for OpenMPT 1.30. Let me know how it works for you.

Test builds should be available in a few hours from



2022-09-27 13:19

reporter   ~0005322

Gave the test build a run, looks good. Thanks!

Issue History

Date Modified Username Field Change
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 / 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 / libopenmpt 0.7.0 (upgrade first) => OpenMPT / 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 / libopenmpt 0.6.6 (upgrade first)