[mythtv] Why allow conflicting bindings (was Re: "New" default keybindings)

[Michael T. Dean]

On 04/24/2007 02:23 PM, David Engel wrote:
> On Tue, Apr 24, 2007 at 11:25:09AM -0400, Michael T. Dean wrote:
>   
>> Perhaps relevant to the discussion:
>> [5896] ( http://svn.mythtv.org/trac/changeset/5896 ) changed the code to 
>> print a warning but allow multiple actions to be bound to the same key 
>> in a context, such that the first action handled by the code wins and 
>> others are ignored.  Why was that approach chosen by David Engel?  Was 
>> it specifically for user-specified mappings (when the user chooses to 
>> create a conflicting binding), or was it meant to help handle new 
>> bindings that create conflicts for the user (meaning changing 
>> RegisterKey() is probably not desirable)?
>>     
> It was to allow user-specified mappings to work around the problem
> that the TV Frontend context is way too broad.  I have the Play button
> on my remote mapped to the 'Y' key which is in turn mapped to the
> PLAYBACK action in "TV Frontend".  Since the PLAYBACK action only has
> meaning in the Watch Recordings and Program Priority screens, my
> remote's Play button was useless in any other "TV Frontend" context.
>
> Allowing conflicts lets me bind other actions to the 'Y' key for use
> in other "TV Frontend" contexts.  For exemple, it lets me keep the
> default binding of 'Y' to the VIEWCARD action which is used in the
> View Scheduled screen.
>   

So, there's really no reason to prevent a developer's chosen "default" 
mapping for a keybinding from creating a new conflict?  That means 
that--since RegisterKey() is only called by REG_KEY(), which is only 
used with string literals--modifying RegisterKey() to check for 
conflicts and ignore the keylist in the event of a conflict would be a 
good thing?

> Admittedly, allowing conflicts was a quick and dirty solution.  A
> better fix might be to add another context level for TV.  For example,
> look for bindings in "TV Specific Screen" first, then in "TV Frontend"
> and finally in "Global".  Another, possbily even better, fix would be
> to add a more generalized way of stacking contexts programatically.
> Both of those changes seemed like overkill at the time when I was the
> only one who had a problem.
>   

Agreed.  And, I'm not sure the times have changed that much.  At least 
they haven't changed so much that I have the same problem (or the 
motivation to create a better implementation).  :)

Thanks,
Mike