[L2Ork-dev] Keyboard grab regression

[Ivica Bukvic]

Plot thickens... It appears as far as I can tell ever since we migrated to
2.x the mouseup events never reach the objects that are clicked on as the
command was hidden behind an if statement that was used only by the tcl/tk
implementation. Adding mouseup event simplifies things a bit, so we may be
able to fix this without changing the order of key command propagation.
That said, I would still like to explore this idea of switching them around
as there may be other benefits...

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



On Thu, Oct 1, 2020 at 8:38 PM Ivica Bukvic <ico at vt.edu> wrote:

> 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/04c10b5c/attachment.html>