[mythtv] Bringing it all together...

Lee Nash lee at compucrew.com
Thu Oct 2 20:07:28 EDT 2003


Are we to assume everybody will be using keyboards or very big remotes to
handle all of these keys?  Obviously, some of the modules (mythbrowser
for instance) will always need a keyboard.  I think if this project really
wants to compete with replay/tivo/<insert pvr of the week> it has to come up
with a UI that requires less keys.

-lee

Quoting D Banerjee <davatar at comcast.net>:

> Ok so it seems the layout you want and the event handles are still being
> hardcoded. May I suggest don't enum or use a file, have the modules or
> "input module" look for event-key entries in the SQL db. If a event-key
> doesn't exist, it never gets used, and the whole shebang becomes
> configurable. The only "drawback" to this is you will always have the same
> key for event "PLAY", which I don't find a bad thing, but you can just
> increase the complexity a notch and make the input wrapper use i.e.
> "PLAY.MUSIC" if exists, otherwise always default to  "PLAY".
> 
> 
> 
> ----- Original Message -----
> From: "Edward Wildgoose" <Edward.Wildgoose at FRMHedge.com>
> To: "Development of mythtv" <mythtv-dev at mythtv.org>
> Sent: Thursday, October 02, 2003 1:16 PM
> Subject: RE: [mythtv] Bringing it all together...
> 
> 
> > > > does this also include a more consistent way of handling user
> > > > input? (no hardcoded keys in each of the modules for example)
> > > >
> > >
> > > The stuff I'm working on doesn't directly touch the user interface,
> > > so if you're working on a dynamic keybinding solution I'd suggest you
> > > keep working.  :-)
> >
> > Hmm..
> >
> > <fag_packet_mode mix_n_match_use_of_syntax = "ON">
> >
> >
> > // Enumerate all input events that we support
> > // UI designers have to work only with these (or add to the list)
> > enum (
> >   KEY_LEFT, KEY_RIGHT, KEY_UP, KEY_DOWN,
> >   KEY_1, KEY_2, .... ,
> >   KEY_FF, KEY_RW, KEY_TRACK_FW, KEY_TRACK_RW,
> >   KEY_MENU, ...
> > );
> >
> >
> > KeyBindingTranslations [255]; //Initialise to empty
> >
> > // Now load up keybindings from file, defaults, etc
> > // eg ...
> >
> > KeyBindingTranslations[val("m")] = KEY_MENU;
> > ....
> > // etc
> >
> >
> > // Do same thing for LIRC events, ie translate button pushes to "events"
> rather than "keys"
> >
> >
> > // Translate Button pushes
> > int Translate (int iKey) {
> > return KeyBindingTranlation[iKey];
> > }
> >
> >
> > /* In the application change from stuff like
> > if (Key = "M") {
> > ...
> >
> > TO:
> > if (Translate(Key) == KEY_MENU) {
> > ...
> >
> > Or..  Better yet pass in the translated keypress to the app by wrapping
> the key input code
> >
> > <fag_packet_mode />
> >
> >
> > Does this miss anything obvious?
> >
> > The point is that UI designers now have a fixed set of "events" to respond
> too, rather than looking for key presses.  LIRC and any other input
> controllers simply have to arrange to emit these events rather than key
> presses.  Now all keyboards look the same - we just need to arrange a way to
> load up alternative layouts into the KeyBindingTranslations table for people
> who want some other set of keys.
> >
> > Note also that several keys can emit the same event.  This means that say,
> the right arrow, AND a multimedia key, and "R" can all emit the "KEY_RIGHT"
> event.


More information about the mythtv-dev mailing list