[mythtv] [mythtv-commits] Ticket #12157: List all recordings with this title (display group)

Michael T. Dean mtdean at thirdcontact.com
Fri May 30 03:31:07 UTC 2014


On 05/29/2014 06:05 PM, Jean-Yves Avenard wrote:
> On 30 May 2014 02:40, Michael T. Dean wrote:
>
>> This is a nice patch--and a feature I've often thought about adding.  My
>> only concern is that generally when we add a new action to MythTV, we leave
>> it without any default binding unless it's a critical action because
>> otherwise any user who has mapped the + key in the TV Frontend or Global
>> contexts will have a key conflict that they're unlikely to figure out, and
>> that will cause confusing behavior that will be reported as bugs.  :(
> can have a new binding name, and use it purely for the recording screen.
>
> why would anyone have mapped the + key in the recording screen?

Note that it's not just the Watch Recordings screen (as the trimmed 
portion of my message described).  It's all the screens that use the TV 
Frontend context (such as Watch Recordings, Upcoming Recordings, 
Recording Rules, Program Guide, Program Finder, ...).

To use some feature in the TV Frontend context that didn't have a 
default binding?  (Such as STOP, CYCLEAUDIOCHAN, VIEWSCHEDULED, 
PREVRECORDED, CUSTOMEDIT, CHANGERECGROUP, or CHANGEGROUPVIEW.)
|
|Or they mapped it to a jump point.

Or they mapped it to a Global action that they actually need in TV 
Frontend contexts.  For example, they may have Global/PAGETOP mapped to 
+ (with Global/PAGEBOTTOM mapped to -) so they can use it to get to the 
top(/bottom) of the Watch Recordings screen in a single button press 
instead of holding down Global/PAGEUP or Global/PAGEDOWN.

> Preventing a great feature for the 1 or 2 people would may have is
> IMHO is great pity...

It's not preventing it--only requires them to bind a key to access it.  
And since different people have different buttons on their remotes (and 
mine doesn't have + on it, and I'd venture it's not the only one), a lot 
of people will need to remap it even if it does have a default binding 
(especially of +).

> those people can read release notes before updating which explain the
> new binding
>
> my $0.01

Well, if someone is going to add a new default key binding, at minimum 
it will require their writing a database update that unbinds the key (+) 
from the given context (TV Frontend) and possibly the Global context 
(though whether to worry about Global is a much harder decision to make 
since things will work fine in some situations and break in others, 
depending on which action it is) and from jump points (and then handling 
all the complaints from users who had that key bound and it no longer 
does what they expect (and they can't access the action they used to use 
with that button) or whose systems don't work properly because the new 
binding shadowed a Global key binding that becomes unavailable in TV 
Frontend for them).

Alternatively (and preferably) a database upgrade should check to see if 
the user has + bound to any action in TV Frontend or Global contexts or 
to any jump point on any host.  If so, it should "manually" create the 
TV Frontend/SELECTDISPLAYGROUP keybinding for that specific host(s) such 
that no key is bound to the action.  (So, any user who had used + in any 
"affected" context/jump point will have no key bound to TV 
Frontend/SELECTDISPLAYGROUP on that host, but all other users will get 
the default of +.)

Of course, since keybindings.keylist and jumppoints.keylist are VARCHAR 
fields that contain comma-separated lists of keys, the logic to check 
whether + is bound will have to handle situations where the entire 
keylist is '+', as well as situations where + is one of multiple keys 
bound to the action ('+,k,e,y' or 'k,+,e,y' or 'k,e,y,+') without 
getting tripped up where + is one character of a key sequence name (i.e. 
'Ctrl+L' or even 'Ctrl++' or--most confusingly--'Ctrl+,'').

If it's worth it to someone to write up that code and thoroughly test 
it, we can add a new default binding.  Otherwise, we need to add the 
action with no default binding and users who want to use it can map the 
key of their choosing (i.e. one that's convenient to them because it's 
already sent from their remote but isn't used in TV Frontend 
and--ideally--makes sense to be used for that action).

Basically, my only requirement is that adding the new action can not 
possibly break anyone's system.

Mike


More information about the mythtv-dev mailing list