[mythtv] Key mapping for BOOKMARK

[Michael T. Dean]

On 03/15/2018 12:54 PM, Peter Bennett wrote:
>
>>> On Thu, Mar 15, 2018 at 08:10:40AM -0400, Michael T. Dean wrote:
>>>> ...our approach in the past has generally been to not provide a 
>>>> default key
>>>> binding for any new actions added to MythTV because the chosen 
>>>> key(s) may
>>>> conflict with a user-mapped binding.  See
>>>> https://lists.gt.net/mythtv/dev/266100#266100 .  Based on the 
>>>> responses in
>>>> this thread--suggesting few people use SELECT to set a bookmark--I 
>>>> would
>>>> consider this to be a not significant case. Therefore, having an empty
>>>> default keylist for SET_BOOKMARK and for TOGGLE_BOOKMARK would make 
>>>> sense
>>>> since there are other approaches by which the user can set a 
>>>> bookmark (even
>>>> by just exiting playback).
>
>
> I am digesting your longer reply to my original email, and it all 
> makes sense. While thinking about a response I came up with another 
> idea that could be much easier and have less impact.
>
> Let the SELECT keys still operate the bookmarks in the way they always 
> have, in conjunction with the AltClearSavedPosition setting. Add the 
> TOGGLE_BOOKMARK and SET_BOOKMARK actions, unassigned to any keys. In 
> the code, support SELECT and the two new actions. The existing 
> functionality will not be changed at all. People who want to use the 
> enter key for pause or other things can map the keys in playback 
> context. They will be able to map bookmarks to other keys if they 
> still want to use bookmarks.
>
> I see there is some precedent for this, in the manual zoom code, where 
> you can assign ZOOM actions but also it uses default actions in the 
> code if a key is used that is not mapped to a zoom action (e.g. left 
> and right).
>
> I am also adding set bookmark and jump to bookmark to the playback 
> navigation menu.

I'd prefer the approach that changes SELECT to no longer have anything 
to do with bookmarks and, instead, change SELECT to do something far 
more commonly-used--like, for example, bring up your navigation OSD 
(which, BTW, thank you for working on that--it is/was something on my 
TODO list***), since navigation is something that is very commonly done 
during playback.  You're welcome to do it the other way, but--if I ever 
get a chance to make time to work on MythTV code, again--I would likely 
eventually remove the SELECT stuff and the setting and just use the 
SET_/TOGGLE_BOOKMARK actions.

Also, we have been working to remove all of the settings that are just 
key bindings in the wrong place--settings that change the way a key 
works--and making all approaches available through different key 
bindings to give more configurability (and discoverability) for users.  
(At least more discoverable from the standpoint that a user should 
assume the answer to the question, "How do I modify how my keys work?" 
should be, "Through key bindings," and not, "Through settings."**)

And I think since you're adding the bookmark functionality to the nav 
menu, it covers the "discoverable for new users, even if the default key 
list is empty" case.

Thanks for all the work you're doing on MythTV--and for helping to pare 
down my TODO list by doing things I had hoped to one day do, like the 
nav OSD. :)

Mike

* FWIW, my plans included allowing users to jump around via prev/next 
commercial marks (marks placed by commercial detection), prev/next cut 
points (marks placed by users), bookmarks (allowing multiple, which I 
think Stuart M modified the code to allow, even though we have no UI to 
do it, yet), and eventually (since I think we'd have to actually start 
writing these from the commercial flagger) blank frames, etc, that come 
from the commercial detection.  I'm not asking you to do any of these 
things, but just giving you an idea of what I had been thinking in case 
you like any of the ideas and hadn' t thought of them.  My main problem 
with getting the nav menu done was figuring out a useable UI/UX, but I'm 
sure you'll do far better than I would have, so maybe it's good I never 
got around to doing it. :)

** And, yes, key bindings are hard to edit and hard to share (between 
frontends and between users), so maybe not the most discoverable place 
for functionality.  I still hope to one day get a chance to modify 
MythTV to use key-binding "themes" (so to speak) such that we can 
export/import key bindings to/from XML files for sharing across systems 
(or even editing) and have several available for selection (or 
auto-selection, for example for Android vs GNU/Linux) such that we no 
longer need to hard-code 
potentially-conflicting-but-hard-to-check-because-they're-spread-out-everywhere 
default key lists in our source code and worry about things like in this 
thread.  Also some users (like Yeechang Lee) have spent a great deal of 
time actually modifying their key bindings to give extremely efficient 
usage of a limited number of keys to allow for use with remote controls, 
and this would give them the opportunity to contribute back various 
bindings that provide various differing options for users.  (Oh, and 
rather than force the use of XML files to share within a system--across 
multiple frontends--the "key bindings theme" setting would allow users 
to select another frontend to copy (at least the current, if not 
automatically updating for future changes to that host's) configuration 
from that frontend.) This approach would even allow 
remote-control-specific bindings, allowing someone to create a 
recommended set of bindings for a given remote or style of remote.  In 
all, it's likely much easier than our current approach.