[mythtv] Bringing it all together...

[Edward Wildgoose]

> > 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.