So far, 1..10 was easy to bind programmatically, because it can be done in a for loop.
Allowing additional keys makes the tool more flexible, but also adds complexity.
Ideas:
the switches could allow a tokenized list of hotkeys, say, --switch-desktop-modifiers CTRL,WIN+0%CTRL,WIN+1
it could be possible to specify switches more than once and each would start binding at 0
"NUMBERS" could be used as an alias for 1..10
"FKEY" could be used as an alias for F1..F12
For much later, perhaps a followup issue:
"KP_NUM" could be used as an alias for KP0 through KP9
"KP_NAV" could be used as an alias for KP_INS through KP_PgUp
These last two are trickier. Windows virtual keycodes don't distinguish keypad directions (e.g. Ins) from a regular Ins. It's probably possible to distinguish them via scancode (https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-kbdllhookstruct), but Win32HotkeyListener's architecture doesn't support this at this point. It would have to allow sub-actions for the same hotkey.
RobertMueller2
commented
4 months ago
So far, 1..10 was easy to bind programmatically, because it can be done in a for loop.
Allowing additional keys makes the tool more flexible, but also adds complexity.
Ideas:
--switch-desktop-modifiers CTRL,WIN+0%CTRL,WIN+1For much later, perhaps a followup issue:
These last two are trickier. Windows virtual keycodes don't distinguish keypad directions (e.g. Ins) from a regular Ins. It's probably possible to distinguish them via scancode (https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-kbdllhookstruct), but Win32HotkeyListener's architecture doesn't support this at this point. It would have to allow sub-actions for the same hotkey.