<div dir="ltr">So, today I had a chance to test out the new exclusive keyboard grab in the version 2.15 with my class and noticed one regression that will require additional adjustments.<div><br></div><div>Namely, now when one clicks on the hslider (or vslider) to drag it, this generates a glist_grab which renders keyboard access to other parts of the patch impossible which is not a desired behavior, since one should be still able to type while dragging a slider with their mouse. </div><div><br></div><div>So, it seems we need an exclusive flag to glist_grab call that can specify if an object wants exclusive focus or not. This will provide greatest flexibility. For instance, numbox when clicked and its number is dragged, may not want exclusive keyboard access since the number is being changed by a mouse. However, as soon as the object receives a key after it has been dragged, it should switch to its exclusive mode that lasts until the user clicks outside the numbox or waits 3 seconds for the focus to time out.</div><div><br></div><div>This, however, will require another foundational consideration. So far, the main keyboard input has worked in the following order:</div><div><br></div><div>1) send key presses to all objects that are bound to key press symbols</div><div>2) then send it to a grabbed object</div><div><br></div><div>For the aforesaid example to work, we will want to have these in reverse order (glist_grabbed first, so that it can intercept the key press and switch the exclusive flag on, which will then prevent passing the key press to bound objects until the object having exclusive focus has released its requested focus).</div><div><br></div><div>Can anyone think of any potential pitfalls of rotating the order of these two? Could this foundationally break patches? I currently cannot think of a scenario where that would be true. The only thing that comes to mind is something where a numbox receives values via receive and also broadcasts user's values, but even then, clicking and dragging would not create an exclusive grab, and once a user starts typing, it will not output a new value until the user presses return. Besides, if someone had this kind of a scenario, I imagine this could easily cause an infinite recursion.</div><div><br></div><div>At any rate, I would love everyone's thoughts on this one.</div><div><br></div><div>Best,</div><div><br></div><div>Ico</div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><pre cols="72"><pre cols="72">-- <br>Ivica Ico Bukvic, D.M.A.<br>Director, Creativity + Innovation
Director, Human-Centered Design iPhD
Institute for Creativity, Arts, and Technology
</pre><pre cols="72">Virginia Tech<br>Creative Technologies in Music<br>School of Performing Arts – 0141<br>Blacksburg, VA 24061<br>(540) 231-6139<br><a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a><br><br><a href="http://ci.icat.vt.edu" target="_blank">ci.icat.vt.edu</a>
<a href="http://hcd.icat.vt.edu/" target="_blank">hcd.icat.vt.edu</a>
<a href="http://www.icat.vt.edu" target="_blank">www.icat.vt.edu</a><br><a href="http://www.performingarts.vt.edu" target="_blank">www.performingarts.vt.edu</a><br><a href="http://l2ork.icat.vt.edu" target="_blank">l2ork.icat.vt.edu</a><br><a href="http://ico.bukvic.net" target="_blank">ico.bukvic.net<br></a></pre></pre></div></div></div></div></div></div></div></div>