This is a wildish proof-of-concept -type thing I call OmniKeys. It didn’t quite seem fit to place it in the tool announcement forum just yet so I’ll put this out here.
----The problem: Tools don’t have customization options for their keyboard shortcuts.
------It’s a problem because: I want (and sometimes NEED) to customize the hard-coded shortcuts.
--------The cause: Unnecessarily hard to program
-----------The solution: A pre-made class to make that task simple (& standardized across tools)
Now I don’t think this is working perfect just yet, but here’s a dummy tool demonstrating what COULD be done with a properly designed class.
The actual tool is just a dummy gui that has some preprogrammed keyboard shortcuts the gui catches. OK. Now, the punchline is that the shortcuts are (hopefully) customizable by the user. The customization, which is admittedly quite clunky right now, is done through a dedicated gui.
To test, summon the actual tool gui from the tools menu entry “DummyGUIforOmniKeyClass”. It just displays uppercase or lowercase random greetings in the textfield. Default keys are “t”, “r”, “shift + t”, “shift + r”.
To customize the keys, summon the customization gui from under the OmniKeys entry in the tools menu. Select the keyboard shortcut you want to customize and modify the keyboard shortcut by editing the textfields under the buttons. After editing, the new shortcuts are immediately active.
(((alpha warnings: only use lowercase letters. only use renoise-lua-api acceptable modifier names and modifier combinations. only use renoise-lua-api acceptable key names and key combinations. disclaimer: too lazy to test and post accepted combinations. maybe will post some here later. hey. it’s friday. c’mon.)))
AND If all goes well, your customized tool shortcuts are written in the tool preferences.xml, under a dedicated xml-node, et voila: customizable per-tool GUI keyboard shortcuts for the masses.
I’m not encouraging anyone to actually use this just yet, but just to describe the usage: To use this in a tool the developer needs the omnikeys.lua -file, which includes the OmniKeysHandler -class.
To generate a dialog which is handled by an OmniKeysHandler -keyhandler, the developer must instantiate an OmniKeysHandler object (e.g. my_omnikeys), and assign my_omnikeys.keyhandler as the dialog’s keyhandler argument, when doing a renoise.app():show_custom_dialog().
When generating the OmniKeysHandler -object the developer defines xml-valid names (for preferences storing) for the different functions that are to be triggered by key presses catched by the dialog, display names to be used in the customization gui, and the functions to be triggered on key presses. Et maybe cetera. And that’s mainly it. The class in turn handles all of the preferences storing, and customization gui generation for the tool.
A.) Whaddya think? Is there potential in something like this?
B.) Anybody want to do this proper?
C.) Should something like this (only working and better) be included ‘natively’ in the xrnx package, actually?