[mythtv-users] Programming remote button bindings (WAS: What major features are planned for 0.27?)

[Michael T. Dean]

On 12/03/2012 04:56 PM, Nigel Pearson wrote:
> On 03/12/2012, at 10:14, Simon did correct Nigel's guess:
>
>> Simon was saying that the kernel defines a KEY_PLAYPAUSE button (it's
>> not a MythTV action name).
>>
>> In MythTV, we have the ones I mentioned.  TV Playback|PAUSE uses
>> DoTogglePause() and TV Playback|PLAY uses DoPlay(), which has different
>> behavior from DoTogglePause().
> (find a source tree, browse libs/libmythtv/tv_play.cpp)
>
> Aah. OK. For some reason I thought there was something
> like an ACTION_TOGGLEPLAY or ACTION_TOGGLEPAUSE, also.
>
>
> ...which could be added, and bound to P,
> instead of both ACTION_PLAYBACK and ACTION_PAUSE.

Currently ACTION_PLAYBACK (TV Playback|PLAY) is bound by default to 
Ctrl+P and ACTION_PAUSE (TV Playback|Pause) is bound to P, but--despite 
the action name--acts as toggle pause.  I don't think anyone would argue 
a need for a discrete pause function, though some seem(?) to like the 
idea of a discrete play function (or at least someone did at some point, 
I'd assume, based on our having one).

I think the current mappings for the keyboard are fine, but the whole 
reason I brought up PLAY and PAUSE actions is because even where it 
seems straightforward to an outside observer that it should be obvious 
how to map the kernel's KEY_PLAY key in MythTV, there's more to 
consider.  (And, for further proof, when the kernel sends KEY_PLAY, does 
Qt receive a Qt::Key_MediaPlay or a Qt::Key_Play--and does it always, on 
all distros, with all kernel versions and all versions of Qt, and ...?)

Anyway, I do think my plan for key bindings "themes" and action mappings 
that support inheritance will solve all the problems with trying to make 
"One True Key Bindings Configuration For All Users And All Remotes".  
The only problem it's going to add is one of "one more thing to 
configure/choose from."  But for most users it will just move this 
decision/configuration from distro-specific configuration tools (like 
where the user chooses a remote control in MythTV Control Center in 
MythBuntu) into MythTV.  But at that point, all distros will benefit 
from the configurability (and potential for ease of configuration) 
without having to create their own remote configuration tools, as well 
as having access to/sharing the different sets of remote- and/or 
functionality-specific mappings that users create.

Mike