[L2Ork-dev] Keyboard grab regression

[Albert Graef]

So what's the short-term fix that you suggest? Do we need to revert
https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/557 until a
proper fix is deployed?

Albert


On Fri, Oct 2, 2020 at 4:36 AM Ivica Bukvic <ico at vt.edu> wrote:

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

-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef at gmail.com, web: https://agraef.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201002/a3d3c4e4/attachment-0001.html>