[mythtv] numeric keys for EPG navigation

[Bruce Markey]

Erik Arendse wrote:
> At 30-1-03 14:01, Bruce Markey wrote:
> 
>> However, I agree with Isaac that some of the key binding
>> have become haphazard and should be reorganized a bit. I
>> think it might help to have more optional keys defined
>> so that things that aren't absolutely necessary can be
>> mapped to keys that are commonly found on remotes.
> 
> 
> I'll go over the source of MC (hopefully tonight) and create a single 
> header which defines two keys for every function. Should be enough for 
> anybody, first key can be used to map to his/her favorite keyboard key, 
> second one to a 'dummy-keyboardkey' just to map a LIRC command to.
> Somebody else can do the other modules later on, using the same header.

I don't think the problem is separating out the the keys
but rather overloading the uses of a small set of keys.
It seems that lirc remaps remote keys to emulate keystrokes
so having two mappings may just make thing more complicated.

The problem is that there are a finite number of keys you
can expect to find on a remote and need to overload their
functions in different contexts to get the most bang of the
buck with the available keys. For example (not literal =) if
the most remotes have select(/ok/enter/go), play, and stop,
you could map these to enter, space, and delete. No problem.
The question is what should select, play and stop do when on
a menu? When in the EPG? When watching Live TV? When watching
a recording? When in edit mode?

One problem, IMHO, is that myth lumps Select and Play together.
Any remote that has arrow buttons and ff/rew buttons should
have separate keys for Select and Play. These should be allowed
to performs two distinct functions in each context (menu, TV,
edit, etc.)

In addition to the minimum defined key set that you must have,
there should also be optional up1, down1, up2, down2, right1,
left1, etc. mapped to +,-, <,> or whatever. This would allow
extra conveniences in different contexts to be overloaded
onto the same keys rather than using a new key for each new
function.

--  bjm