[mythtv] Why allow conflicting bindings (was Re: "New" default keybindings)
Michael T. Dean
mtdean at thirdcontact.com
Tue Apr 24 23:31:41 UTC 2007
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:
>>  ( 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
> 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). :)
More information about the mythtv-dev