[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