[mythtv-commits] Ticket #3642: "Program guide in live tv" keybinding overrides guide jump point

MythTV mythtv at cvs.mythtv.org
Sun Feb 3 05:41:18 UTC 2008


#3642: "Program guide in live tv" keybinding overrides guide jump point
-------------------------+--------------------------------------------------
 Reporter:  anonymous    |        Owner:  cpinkham
     Type:  enhancement  |       Status:  closed  
 Priority:  minor        |    Milestone:  0.21    
Component:  mythtv       |      Version:  head    
 Severity:  medium       |   Resolution:  fixed   
  Mlocked:  0            |  
-------------------------+--------------------------------------------------
Changes (by cpinkham):

  * status:  assigned => closed
  * resolution:  => fixed


Comment:

 A modified version of this patch was applied in [15736]. So, I'm closing
 this ticket but wanted to address the questions raised by Roo.

 Replying to [comment:16 Roo <roo.watt at gmail.com>]:
 > Replying to [comment:14 cpinkham]:
 >
 >  * I wonder if there is a need to extend the jumppoint table with the
 extra column?
 > Just leave the localactions defined in code, if in the future the local
 actions are
 > changed (in code) then the db wouldn't need to be updated.

 I took this commented out code out of my patch, so the DB isn't touched.

 >  * If the keybinding and the jumppoint are set to different keys then
 the jumppoint
 > still gets used, bit awkward in the setup aspect.

 I don't see this as a problem.  If the user doesn't define them both the
 same then it could lead to situations where we aren't sure what they
 actually want to do.  Consider if I assign 'S' to GUIDE and '#' to FINDER
 in the TV Playback context, but I assign '#' to the Program Guide
 jumppoint and 'S' to the Program Finder jumppoint.  This is a contrived
 example, but holds true for any case there the same key is used for a
 different local action and jumppoint.  If the user hits '#' while watching
 a recording, did they want the Program Finder because of the local key
 binding for the context or did they want the Program Guide because of the
 jumppoint?  That is the reason that I require both keys to be the same for
 the jumppoint and the local action.

 >  I wonder if it is worth registering a "context,action" pair, then
 !TranslateKeyPress()
 > could check the context and return the matching local action instead of
 the jumppoint.

 I didn't want to tie it to that.  If the localAction is defined in the
 current context and the keys match, then the localAction is preferred.  No
 need to specify a lists of contexts that apply.  If we didn't want to be
 able to use the localAction in the current context, we wouldn't have added
 the handling code for it, so I think it makes sense to prefer the
 localAction if it exists in the current context and the keys match.

 > This would have the added advantage that the local keybinding doesn't
 have to be the
 > same as the jumppoint. Actually, there would be no need to have the "TV
 Frontend" GUIDE
 > action bound if you have the GUIDE jumppoint set. This was one of the
 things I liked
 > about the alternate approach.

 I considered allowing the localAction to be used if there were no keys
 bound to it, rather than requiring the key be the same as the jumppoint,
 but that will require more invasive changes because we currently don't
 have a way to lookup an action to see what actions are defined in a given
 context or what keys associate with that action.  This  is possible, we
 just don't track things this way right now.  The KeyContext class in
 mythmainwindow.cpp would have  to be modified to support this if you want
 to take a look at implementing it.  The changes are minor, but given the
 fact that localActions in question already have default key assignments,
 it would be rare for them to be empty.

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/3642#comment:17>
MythTV <http://svn.mythtv.org/trac>
MythTV


More information about the mythtv-commits mailing list