[mythtv] "New" default keybindings

Micah Galizia micahgalizia at gmail.com
Tue Apr 24 04:20:07 UTC 2007

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

> >  I think that users should be prevented from messing up their
> >  bindings.
> Agreed, but the situation I'm talking about happens before the users
> have a chance to set keybindings (or mess up keybindings).  (For all
> practical purposes, I'm talking about keys.txt, not about the
> keybindings table in a user's database--the /default/ mappings the user
> gets if she doesn't change them.)

now I'm with you!

>  Also, what does writing an empty keylist do?  I don't see
> >  how it fixes anything.  Please elaborate.
> When a developer adds a new keybinding to Myth (not new to a specific
> configuration, but new to the MythTV application), the current options
> are to create the keybinding and let users discover it for themselves
> (i.e. do not provide a /default/ mapping for it--write an empty keylist)
> or provide a default mapping, which will cause RegisterKey() to write to
> the database a keybinding that uses that default mapping (the specified
> keylist) the first time the the context is accessed.

In that case I think leaving it empty would be the simplest way to do it.

So, for example, [13315] added a new keybinding for an action called
> PLAY in the Music context.  This action didn't previously exist in
> MythMusic.  Therefore, before this change no one had a mapping for PLAY
> in Music context, and it's impossible to add one through
> MythControls--the binding doesn't exist.  Once the user upgrades, the
> first time the MythMusic plugin is init'ed, it will register a key for
> the action.
> [13315] took the option of specifying an empty keylist--i.e. forcing the
> user to create his own binding if he wants to use PLAY.  Had [13315]
> specified a default mapping of Ctrl+P (as is used for TV Playback's
> PLAY), any user who had already specified a mapping for Ctrl+P would
> automatically get a conflicting binding--just because his configuration
> was different from the developer's.  Nothing prevents the conflict from
> being written to the database.  However, MythControls will later help
> the user fix it (and will check to ensure the user doesn't specify any
> new conflicts), but the in-C++-code default bindings are written without
> any checks.

Yeah, I think just leave it blank unless your going to do conflict
checking.  There is some _simple_ conflict checking code in mythcontrols,
but because different plugins (such as mythvideo) use actions from an
assortment of contexts, its impossible to do proper conflict resolution.
This is why I was thinking about a registry.  So plugins could register the
keys they use and we could really know what bindings will conflict.

If RegisterKey() checked for conflicts before blindly accepting the
> "requested default keylist," we would actually be protecting the users.
> Currently we don't.  Instead, after the binding is written to the
> database, we simply write out a message in the logs that there's a
> conflicting binding every time we read in the bindings.  Most users
> never see/notice these.


So, the /only/ way I can think of to handle a conflict in RegisterKey()
> is to either create the new record in the DB using the "requested
> default keylist" if there's no conflict or create the new record using
> an emply keylist--i.e. make the user specify a keylist him/herself
> through MythControls or whatever--if there is a conflict.

Seems logical.
"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/bce80f89/attachment.htm 

More information about the mythtv-dev mailing list