[WIP][Discussion] Key codes constants

[monsieurh]

This PR is for discussion only at the moment.
A:Purpose

1. Provide a centralized place for developers to find all handled keycodes
2. Provide a way to uses aliases and hack around the mapping on all applications
3. Provide centralized functions to check if an input is a validation or not (enforcing keymap consistency accross appsum)

B:WIP
If the proposition is accepted, I'll update all usages of the keycodes in ZPUI accordingly

[CRImier]

Adding the IRC conversation here, so that it doesn't get lost:

[10:48] <monsieur_h> the code might help, the summary is not that good 
[10:48] <monsieur_h> https://github.com/ZeroPhone/ZPUI/pull/26/files 
[10:49] <monsieur_h> So the goal was to provide an enum with all keys 
[10:49] <monsieur_h> and a centralized place to check if an input is a validation or else 
[10:49] <monsieur_h> so if you want to change the keymap system-wide, you just have to do it there 
[10:49] <monsieur_h> (Adding a config file would be good for this, i suppose) 
[10:50] <CRImier> The problem isn't about changing the keymap system-wide, actually 
[10:51] <CRImier> The task is providing a user-friendly app for mapping certain keys to user-defined actions, and the problem is making an infrastructre for doing that 
[10:51] <CRImier> *infrastructure 
[10:53] <monsieur_h> well, the first step to achieve this is to have a centralized keymap in my opinion 
[10:53] <monsieur_h> thinking about a different design ? 
[10:55] <CRImier> monsieur_h: for now, I'd rather remain with string constants 
[10:56] <CRImier> Since having an enum with a hard-coded key name referring to a string with the same name seems to be not that useful to me 
[10:57] <CRImier> It's an additional layer of abstraction, so what'd be this layer's pros and cons? What does this layer provide us with, and what does it take away? 
[10:59] <CRImier> I like the confirm() and cancel() functions, and I can imagine how a set_cancel(), get_cancel() and is_cancel() functions would be useful 
[11:00] <CRImier> set_cancel(i) being a helper to auto-set multiple callbacks to be tied to your app's "cancel()" function, for example 
[11:01] <CRImier> However, there's already an ExitHelper helper object for that 
[11:02] <CRImier> Hmm. Come to think of it, ExitHelper's existence doesn't negate the *_cancel() function usefulness =) 
[11:02] <CRImier> So, I like the functions, but I'm not sure the enum is necessary, if all it does is allows to map keys to other keys system-wide 
[11:04] <CRImier> That said, I can also imagine an is_valid_keyname() function being useful 
[11:06] <CRImier> Tie it to InputProxy's set_keymap and set_callback functions, and make it throw exceptions if the keyname doesn't start with KEY_, BTN_, REL_ or anything else that could be thrown by the hid driver if somebody decides to attach a keyboard to ZPUI and use it the way he wants 
[11:11] <CRImier> The problem with the enum is also that, if we're adding all those key_names to it, we also would need to suggest people use these, and then we'd need to write an additional import statement at the beginning of each app, and write "enum.KEY_ENTER" instead of just "KEY_ENTER", which seems like an awful lot of effort for processing a special case that I don't yet see a usecase for - so, I'm waiting for your input on that =) 

[monsieurh]

Adding to the confirm() and cancel() function, a nice one would be option(). I think we should support a standardized way to bring an option menu from anywhere in ZPUI (if available).

Enforcing a common scheme for all app developpers is going to be hard so having a similar scheme is_option(key) and set_option_key(key) would help.

It would avoid the burden of reinventing the wheel/option-menu on every app.

[CRImier]

Absolutely agree on the option()! At the Key codes Wiki page, you can see that you could probably use KEY_F1 or F2, for a start. Which one is better to use, though, is a good question - I'll look at which one is used on my personal dumbphones =)

[CRImier]

I have this old idea - each input device, theoretically, can provide different keycodes. What if we expose a list of all possible-to-receive keycodes as a property of the i object? How do you think, would it be useful, or so-so? (I'm falling asleep right now so can't figure it out myself, sorry =) )