[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
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,  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
 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 
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
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