[L2Ork-dev] Keyboard grab regression

Ivica Bukvic ico at vt.edu
Thu Oct 1 20:38:59 EDT 2020


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.

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.

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.

This, however, will require another foundational consideration. So far, the
main keyboard input has worked in the following order:

1) send key presses to all objects that are bound to key press symbols
2) then send it to a grabbed object

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).

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.

At any rate, I would love everyone's thoughts on this one.

Best,

Ico

-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Director, Human-Centered Design iPhD
Institute for Creativity, Arts, and Technology

Virginia Tech
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico at vt.edu

ci.icat.vt.eduhcd.icat.vt.eduwww.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201001/71e9b189/attachment.html>


More information about the L2Ork-dev mailing list