<br><br><div><span class="gmail_quote">On 4/24/07, <b class="gmail_sendername">Michael T. Dean</b> &lt;<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</a>&gt; 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;">
&gt;&nbsp;&nbsp;I think that users should be prevented from messing up their<br>&gt;&nbsp;&nbsp;bindings.<br><br>Agreed, but the situation I&#39;m talking about happens before the users<br>have a chance to set keybindings (or mess up keybindings).&nbsp;&nbsp;(For all
<br>practical purposes, I&#39;m talking about keys.txt, not about the<br>keybindings table in a user&#39;s database--the /default/ mappings the user<br>gets if she doesn&#39;t change them.)</blockquote><div><br>now I&#39;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;">&gt;&nbsp;&nbsp;Also, what does writing an empty keylist do?&nbsp;&nbsp;I don&#39;t see<br>&gt;&nbsp;&nbsp;how it fixes anything.&nbsp;&nbsp;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.&nbsp;&nbsp;This action didn&#39;t previously exist in<br>MythMusic.&nbsp;&nbsp;Therefore, before this change no one had a mapping for PLAY<br>
in Music context, and it&#39;s impossible to add one through<br>MythControls--the binding doesn&#39;t exist.&nbsp;&nbsp;Once the user upgrades, the<br>first time the MythMusic plugin is init&#39;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.&nbsp;&nbsp;Had [13315]<br>specified a default mapping of Ctrl+P (as is used for TV Playback&#39;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&#39;s.&nbsp;&nbsp;Nothing prevents the conflict from
<br>being written to the database.&nbsp;&nbsp;However, MythControls will later help<br>the user fix it (and will check to ensure the user doesn&#39;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.&nbsp; 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.&nbsp; This is why I was thinking about a registry.&nbsp; 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>&quot;requested default keylist,&quot; we would actually be protecting the users.
<br>Currently we don&#39;t.&nbsp;&nbsp;Instead, after the binding is written to the<br>database, we simply write out a message in the logs that there&#39;s a<br>conflicting binding every time we read in the bindings.&nbsp;&nbsp;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 &quot;requested<br>default keylist&quot; if there&#39;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>&quot;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.&quot;&nbsp;&nbsp; --W. Stekel