[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