[mythtv] numeric keys for EPG navigation

[Erik Arendse]

At 31-1-03 10:36, Bruce Markey wrote:
>Erik Arendse wrote:
>>At 31-1-03 01:14, Bruce Markey wrote:
>...
>>My idea:
>>- map functions to a key you like on the keyoard
>>- reserve a (for yourself) 'useless' keyset to be used one-on-one with 
>>your remote buttons (think ctrl-shift A-Z or something)
>>- map you remote buttons with lirc to the 'useless' keyset for mythtv
>>- now you can map buttons from your remote by using the 'useless' set, 
>>combining functions on a single key even though on the keyboard you use 
>>separate keys.
>...
>>I want to implement a non-limited list of keys definable for each 
>>function, that way you could for instance map up, ctrl-up, shift-up, 
>>grey-up, 'u', 'Q', 'W' to the function KEY_EPG_ROWUP, and map your remote 
>>buttons 'program up' and 'cursor up' to keyboard 'Q' and 'W'.
>
>I read this several times to see if there was something
>implicit that I didn't grasp. I think your idea of multiple
>keys to a function makes sense. However, it's not clear to
>me how/if you will have one key map to several functions.
>
>If I'm at a keyboard, I want the right arrow to do several
>things. Can I assume that right arrow can be mapped to
>KEY_MENU_RIGHT, KEY_EPG_TIME_FORWARD KEY_LIVE_FASTFORWARD,
>etc.?
Yes.

First one thing: I will probably leave most QT-widget-keys untouched, that 
is things like cursorkeys and dataentry in dialogs etc. Rule of thumb: if 
it isn't hardcoded right now, I probably won't make it configurable in the 
first version. Maybe I'll even leave in cursorkeys for very basic functions 
to avoid having a user map one-cell up/down/left/right in the EPG while 
he/she can't map the same functions in a dialog.
As a side-benefit this avoids messing up the setup module for the keys 
itself...

Lets be verbose on the mapping to avoid misunderstanding:
Lets say inside the current code there is a check is a key 'U' is pressed 
for going up in the EPG.
I will replace this with a call like iskeypressed(KEY_EPG_ROWUP).
A similar check will be in the livetv module to go up one channel. I will 
replace this with iskeypressed(KEY_LIVETV_CHANNELUP)
In the header will be defined
- KEY_EPG_ROWUP has context KEYCONTEXT_EPG defaults {up-arrow, 'u'}
- KEY_LIVETV_CHANNELUP has context KEYCONTEXT_LIVETV {pgup, 'u'}
Without discussing my hypothical defaults:
- The ambiguity test (see below) succeeds ('u' doesn't clash as the 
contexts differ).
- iskeypressed(KEY_EPG_ROWUP) will be true if up-arrow or 'u'  was pressed
- iskeypressed(KEY_LIVETV_CHANNELUP) if pgup or 'u' was pressed

>These don't conflict since they are in different
>contexts. How would you avoid a user error of assigning
>a key to two functions that may occur in the same context?
Should be the task of the setup module. The global defining header should 
for every function define:
- the name of the function (KEY_LIVETV_FASTFORWARD)
- the context (KEYCONTEXT_LIVETV)
- the default key(s) (for example trl+rightarrow and 'f')
The setup could use the context to check for ambiguities.

>This may not be a problem but I wonder what happens when
>a new function is added? You may not be able to use a
>default key binding since it may interfere with the user's
>customizations. How does the user discover there is a new
>function label that she needs to bind to a key?
The defaults should cover most of the situations, but the context-ambiguity 
check could run on startup while initializing the key-map cache. Maybe jump 
to setup automatically if any errors, or just report in a box which 
functions conflict.

Erik
PS: thanks for thinking along, sometimes it's better to sit and think than 
start coding :-)