[mythtv] "New" default keybindings
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,  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.
>  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
> 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.
"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."
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-dev