pretty typical to use different hotkeys in different situations, or on e.g. different keyboards (I use cmd+up/down/left/right for large cursor actions for example, but I'd like to keep the PageUp/PageDown versions around), or to allow same defaults to support users with varying expectations.
I'm not as excited about it as I was at one point, but it still seems like a nice-to-have for a typical tool, and a must-have for a mature or power-user-friendly tool. The change is also not too complicated.
Implementation:
store action keys as vectors of ints rather than as ints, taking advantage of DivConfig's existing (unused?) ability to save/load vectors of ints. "0" shouldn't be stored anywhere (e.g. no bindings would be an empty vector). a single value of "-1" is used to indicate "not a binding", like how it was previously
update uses of getKeyName in menus to show multiple keybinds in menus (i think this is the standard, rather than showing e.g. just the first)
update Keyboard settings menu to show "+" to add additional keybinds
added an "x" button to remove keybinds rather than just using right-click (it's more important to be discoverable now, since users now have a good reason to remove keybinds rather than merely replace them)
Caveats:
i think we could now add a bunch of alternate keybinds to help new users get up to speed (e.g. ctrl-up/down for coarse cursor movement, since most laptop users won't even have page up/down), but we would want some logic to prevent new defaults from conflicting with old custom bindings...
the bindSetActive/bindSetPending stuff feels a bit brittle in general, i wouldn't be surprised if i broke it in some subtle way, but i've resolved all issues i've been able to find
Use case:
pretty typical to use different hotkeys in different situations, or on e.g. different keyboards (I use cmd+up/down/left/right for large cursor actions for example, but I'd like to keep the PageUp/PageDown versions around), or to allow same defaults to support users with varying expectations.
I'm not as excited about it as I was at one point, but it still seems like a nice-to-have for a typical tool, and a must-have for a mature or power-user-friendly tool. The change is also not too complicated.
Implementation:
Caveats:
bindSetActive/bindSetPending
stuff feels a bit brittle in general, i wouldn't be surprised if i broke it in some subtle way, but i've resolved all issues i've been able to findPics: