[L2Ork-dev] Keyboard grab regression

[Ivica Bukvic]

I wouldn't revert it just yet. If my fix is ready in the next 24 hours
(which is likely as I am 80% there and have most of the major issues worked
out), then we can simply do a new release.

Best,

Ico

-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
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

www.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Fri, Oct 2, 2020, 00:59 Albert Graef <aggraef at gmail.com> wrote:

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