[mythtv-commits] Ticket #11916: Frontend Services API inconsistent with direct key input, lirc, and network control socket

MythTV noreply at mythtv.org
Tue Oct 22 03:15:38 UTC 2013


#11916: Frontend Services API inconsistent with direct key input, lirc, and network
control socket
----------------------------------------------+----------------------------
 Reporter:  skd5aner <skd5aner@…>             |          Owner:
     Type:  Bug Report - General              |         Status:  new
 Priority:  minor                             |      Milestone:  unknown
Component:  MythTV - Services API - Frontend  |        Version:  0.27-fixes
 Severity:  medium                            |     Resolution:
 Keywords:                                    |  Ticket locked:  0
----------------------------------------------+----------------------------

Comment (by mdean):

 On initial code review, it looks like the code is working properly--though
 the user interface is, at minimum, confusing to the user or possibly just
 plain wrong.

 When using the keyboard, LIRC, or network control socket, the user is
 sending keys to MythTV.  Those keys are then interpreted by mythfrontend
 based on how the user has bound those keys to MythTV actions.

 However, when using the frontend services API, the user is sending a
 MythTV action directly--not sending a key that MythTV will interpret based
 on the user's key bindings.  So, the "interpreted" action that Matt is
 expecting is actually TV Playback/SEEKRWND and can be achieved with:
 http://frontendip:6547/Frontend/SendAction?Action=SEEKRWND

 It seems that the frontend services API just needs a SendKey method to
 provide a user-friendly means of direct user interaction.

 Whether the frontend services API should expose SendAction is another
 question, but 3rd-party applications definitely should not use SendAction
 as a means of sending keys to MythTV.  Instead, the current design seems
 to require 3rd-party applications to reconstruct the MythTV keybindings
 implementation using GetContextList and GetActionList to determine the
 keys the user has bound and attempt to guess how mythfrontend will
 interpret that key and then send the action to which the key is bound
 (even though the 3rd-party application doesn't necessarily know which
 context mythfrontend is currently using to interpret keys and a given key
 can be bound to different actions in different contexts).  Therefore, a
 SendKey method, which allows the frontend to interpret whatever key the
 user sends, makes more sense for creating keyboard/remote functionality in
 applications.

 My initial feeling is that it's fine for us to expose SendAction, but
 doing so will be a point of confusion for users (including both 3rd-party
 application developers and their users)--especially until/unless we have a
 SendKey action that is consistent with all the other interface options and
 all 3rd-party applications are changed to use it for providing user
 interactivity (remote/keyboard functionality).  It seems that already-
 existing 3rd-party applications have used SendAction thinking it was a
 means of providing keyboard/remote control of a frontend, though it is
 not.  The SendAction method simply allows 3rd party applications to send
 specific action requests regardless of the user's key bindings; however
 any direct user interaction in those 3rd party applications should use
 (the currently non-existent) SendKey method to provide a means for the
 user to control the frontend, as if using a keyboard/remote.

 However, since we don't allow users to send already-interpreted actions
 using any other interface, one could argue we should not expose
 SendAction.

--
Ticket URL: <http://code.mythtv.org/trac/ticket/11916#comment:2>
MythTV <http://www.mythtv.org>
MythTV Media Center


More information about the mythtv-commits mailing list