[mythtv] "New" default keybindings

Micah Galizia micahgalizia at gmail.com
Tue Apr 24 00:05:54 UTC 2007


On 4/24/07, Michael T. Dean <mtdean at thirdcontact.com> wrote:
[snip]

While writing the code (attached), I had two options for handling
> situations where users didn't already have a keybinding for the PLAY
> action in the Music context.  The first was to create one in the dbcheck
> update.  The second was to allow REG_KEY to do it for me.
>
> However, REG_KEY (specifically, MythMainWindow::RegisterKey()) does not
> check for conflicts with existing bindings when adding a new binding to
> the DB.
>
> So, I think that leaves us three options for new default keybindings.
> The first option would be to modify RegisterKey() to use (and write to
> the DB) an empty keylist if a conflict is found for a requested new
> binding (i.e. one that is not yet in the DB).  The second option is to
> make it policy that the users should fix their bindings (after all, we
> do log the message, "Key <whatever> is bound to multiple actions in
> context <wherever>").  And, the third option is to never add new default
> keylists for new bindings (or some combination of 2 and 3--add it and
> let users fix it for critical bindings and don't add "nice-to-have"
> bindings).


I think that users should be prevented from messing up their bindings.  We
cannot stop them from going into the database and mucking around, but
through the UI they shouldn't be able to screw things up.  Also, what does
writing an empty keylist do?  I don't see how it fixes anything.  Please
elaborate.

I'm probably going to be shot for suggesting this, but I think we should
stop using contexts.  I know we need different actions in different
situations (contexts), but maybe we could come up with a nice set of actions
that work in all situations.  This might restrict the functionality for some
users with little remotes, and it'd also require rewriting the key press
handling in all of the plugins so that they used the one set of actions, but
in the end I think it would simplify the frontend for developers and users.

If that idea is out of the question, another thought I had a while back was
to maintain an actual registry of key bindings that has logic and prevents
conflicts.  It would simplify the logic in Mythcontrols, but only because it
would be introduced into the main program.  We could write it to prevent
registration of inappropriate keys, event if they are written into the
database.

The attached patch may help illustrate the point.  Because it relies on
> REG_KEY to create new entries, it only checks for conflicts for users
> who used MythMusic after [13315], but before the patch was applied (i.e.
> those who already have a PLAY action in Music context).  Those who never
> used one of those "in between" versions would never benefit from the
> conflict-checking code.  By modifying the patch to explicitly add PLAY
> bindings for the Music context to the DB when there is none, we can
> benefit from conflict-checking.  However, with this approach we would
> require a DB update for every new default keylist we want to add without
> introducing conflicts.

Would changing RegisterKey() (to do a conflict check and use a blank
> keylist if one is found) be a good thing or are we relying on the users
> to see the conflict messages and fix their bindings themselves?


I think it'd be cool if RegisterKey did check for conflicts, but I must be
missing the point your trying to make.  How will a blank keylist help
resolve a conflict?

Cheers!
-- 
"The mark of an immature man is that he wants to die nobly for a cause,
while the mark of the mature man is that he wants to live humbly for one."
--W. Stekel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20070424/071bdb49/attachment.htm 


More information about the mythtv-dev mailing list