<br><br><div><span class="gmail_quote">On 4/24/07, <b class="gmail_sendername">Michael T. Dean</b> <<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</a>> wrote:</span><br>...<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> I think that users should be prevented from messing up their<br>> bindings.<br><br>Agreed, but the situation I'm talking about happens before the users<br>have a chance to set keybindings (or mess up keybindings). (For all
<br>practical purposes, I'm talking about keys.txt, not about the<br>keybindings table in a user's database--the /default/ mappings the user<br>gets if she doesn't change them.)</blockquote><div><br>now I'm with you!
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Also, what does writing an empty keylist do? I don't see<br>> how it fixes anything. Please elaborate.
<br><br>When a developer adds a new keybinding to Myth (not new to a specific<br>configuration, but new to the MythTV application), the current options<br>are to create the keybinding and let users discover it for themselves
<br>(i.e. do not provide a /default/ mapping for it--write an empty keylist)<br>or provide a default mapping, which will cause RegisterKey() to write to<br>the database a keybinding that uses that default mapping (the specified
<br>keylist) the first time the the context is accessed.</blockquote><div><br>In that case I think leaving it empty would be the simplest way to do it.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So, for example, [13315] added a new keybinding for an action called<br>PLAY in the Music context. This action didn't previously exist in<br>MythMusic. Therefore, before this change no one had a mapping for PLAY<br>
in Music context, and it's impossible to add one through<br>MythControls--the binding doesn't exist. Once the user upgrades, the<br>first time the MythMusic plugin is init'ed, it will register a key for<br>the action.
<br><br>[13315] took the option of specifying an empty keylist--i.e. forcing the<br>user to create his own binding if he wants to use PLAY. Had [13315]<br>specified a default mapping of Ctrl+P (as is used for TV Playback's
<br>PLAY), any user who had already specified a mapping for Ctrl+P would<br>automatically get a conflicting binding--just because his configuration<br>was different from the developer's. Nothing prevents the conflict from
<br>being written to the database. However, MythControls will later help<br>the user fix it (and will check to ensure the user doesn't specify any<br>new conflicts), but the in-C++-code default bindings are written without
<br>any checks.</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If RegisterKey() checked for conflicts before blindly accepting the<br>"requested default keylist," we would actually be protecting the users.
<br>Currently we don't. Instead, after the binding is written to the<br>database, we simply write out a message in the logs that there's a<br>conflicting binding every time we read in the bindings. Most users<br>
never see/notice these.</blockquote><div><br>Agreed. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So, the /only/ way I can think of to handle a conflict in RegisterKey()
<br>is to either create the new record in the DB using the "requested<br>default keylist" if there's no conflict or create the new record using<br>an emply keylist--i.e. make the user specify a keylist him/herself
<br>through MythControls or whatever--if there is a conflict.<br></blockquote></div><br>Seems logical.<br>-- <br>"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