Adding Action processing into InputProcessor

[CRImier]

ZeroPhone, and some other platforms that can run ZPUI, have spare keys that can be used with various ZPUI functions. Currently, the way to bind a function to a key is adding a non-maskable callback in code of the app that contains the desired function - for example, here's how it's currently done for volume buttons and for "Next"/"Previous" MOCP player control app actions. It's an option that works, but it's not easily configurable:

1. User shouldn't have to edit the code in order to remap a key to another function
2. Having these mappings in code prevents them from being changeable using ZPUI itself, and having an in-ZPUI menu that'd enable the user to remap their keys would be the most user-friendly solution I can currently think of.

My idea is to have apps register some kind of "actions" into ZPUI, say, app-specific functions, during app import process. ZPUI then would have a list of available actions, and the user could access that list and map actions to keys - the actions would be then registered as non-maskable callbacks. Once a key is pressed, the action would be resolved into a function and executed. Possible problems with this approach:

1. If an action interacts with the display or changes the keymap, the changes will affect the currently running app. So, a multicontext system ( #8 ) is needed.
2. More?

[CRImier]

Plan:

create a system for apps and users to set hooks on keypad key press/hold events, essentially, have same behaviour people expect from keypad phones, but also accessible for users, and with ways to change button-to-action mappings.

• set a global "hold HANGUP to switch to shutdown app" hook

  • disable HANGUP hook once in the app itself
  • set a local "hold HANGUP to shut down" action instead
  • allow still using simple presses of HANGUP in i.e. calls
  • plan - SwitchContextAction with key_suitable=True and default_key="KEY_HANGUP"

• set a global "hold LEFT to switch to main screen" hook

  • still allow LEFT presses - make sure to process them unless it's a hold event
  • plan - Action with key_suitable=True, default_key="KEY_LEFT", default_state="HOLD"; user can reassign

• set a global "press PROG1 to do X" hook

  • also be able to set a "hold PROG1 to do Y" hook
  • when PROG1 is held to execute Y, X should not fire?
    • move "X" action from PRESSED to RELEASED automatically and inhibit it if HELD was triggered?
    • should we give the users opportunity to still do both PRESSED and HELD explicitly, even though it's counter-intuitive and will conflict? Will giving such opportunity interfere with the "PRESSED/HELD conflict" solution?
  • plan - Action with key_suitable=True, default_key="KEY_PROG1" (default_state="PRESS" by default), user can reassign

• allow an app to set "hook to use with a button"

  • user should be able to set it to any button or not use it at all
  • app should be able to suggest a key to be auto-used, i.e. VOLUME buttons for volume actions
  • plan - Action with key_suitable=True, default_key="KEY_PROG1", user can reassign both

Optional:

• set a global "double press PROG1 to do X" hook
  • also be able to set "press PROG1 to do Y" and "hold PROG1 to do Z"
  • needs some kind of background thread to execute Y if press isn't a double one? or other option.
  • plan - add a check to InputProcessor.event_loop()? We only need to execute the callback if the key hasn't been pressed the second time, and our input thread only processes stuff when a key is pressed.