[mythtv] "New" default keybindings

Michael T. Dean mtdean at thirdcontact.com
Tue Apr 24 04:03:54 UTC 2007

On 04/23/2007 08:05 PM, Micah Galizia wrote:
>  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).


>  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.)

>  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.

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.

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.


More information about the mythtv-dev mailing list