[L2Ork-dev] Purr Data 2.14.2

[Albert Graef]

On Fri, Sep 25, 2020 at 2:26 PM Ivica Bukvic <ico at vt.edu> wrote:

> I like the new approach because it just proposes two different modes of
> operation without introducing yet another hybrid one.
>

I'm not sure I understand, are you talking about my solution, or Jonathan's
second proposal?

If it's the latter, yes, the more I think about it, the more it makes sense
to reduce all the flashing to a bare minimum by deferring temp runmode to
modifier-click. But someone will now just have to bite the bullet and
implement that. ;-) I already had my turn, and nobody seems to like what I
came up with, even though it fixes (almost) all the really bad regressions
we had with the Ctrl modifier.

Regardless the approach, we still need the ghost key release fix that
> Jonathan proposed.
>

Yep, to fix the modifier-click issue on a subpatch if nothing else.

Albert


On Thu, Sep 24, 2020, 20:57 Albert Graef <aggraef at gmail.com> wrote:
>>>
>>>> On Thu, Sep 24, 2020 at 6:12 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
>>>> wrote:
>>>>
>>>>> I mentioned one solution previously, which was to just go ahead and
>>>>> send a ctrl up event to the backend in the relevant callbacks. To sum
>>>>> up-- it's more involved than simply changing the keybinding.
>>>>>
>>>>
>>>> Yep, that's what I referred to as "a lot of duct tape." :)
>>>>
>>>> I think there is another-- instead of triggering the beginning of the
>>>>> mode on `<ctrl>`, we could trigger it on click.
>>>>
>>>>
>>>> That sounds like the most sensible solution. But is that really the
>>>> only thing that you can do in temp runmode? (Sorry, I'm not actually that
>>>> familiar with temp runmode, I don't really use it a lot myself.)
>>>>
>>>> Also, do you think that this also solves the popup-swallows-ctrl-key-up
>>>> bug in the case of an abstraction click in temp runmode? (Joseph just
>>>> reported this for 2.14.2, it's the one popup issue which remains the same
>>>> with the Alt keybinding.)
>>>>
>>>> Albert
>>>>
>>>>
>>>> Then we can just look
>>>>> to see if there's a `<ctrl>` modifier with the click, and if so send
>>>>> that `<ctrl>` key event to the backend. Now the backend can wait with
>>>>> impunity for the `<ctrl>` keyup since we know the user is in the midst
>>>>> of a click.
>>>>>
>>>>> To be completist we could do the same for an initial mousemove event
>>>>> to check if `<ctrl>` is depressed. That would leave a single esoteric
>>>>> bug, which is that the user wouldn't be able to trigger a pointer
>>>>> cursor change-- say, hovering over a scalar's clickable hotspot--
>>>>> simple by depressing and release `<ctrl>`.
>>>>>
>>>>> -Jonathan
>>>>>
>>>>> >
>>>>> >> I vote for keeping the <ctrl> binding.
>>>>> >
>>>>> >
>>>>> > Counted, thanks.
>>>>> >
>>>>> > It probably doesn't come as a big surprise that I vote for the Alt
>>>>> key myself. ;-)
>>>>> >
>>>>> > Anyone else? Ico, IIRC it was actually you who originally suggested
>>>>> the Alt key (or would at least be fine with it), so what's your vote then?
>>>>> >
>>>>> > Cheers,
>>>>> > Albert
>>>>> >
>>>>> >> >>> I also see the new grid in Edit mode. Is there any way to snap
>>>>> to this grid?
>>>>> >> >>
>>>>> >> >> And this...?
>>>>> >> >> _______________________________________________
>>>>> >> >> L2Ork-dev mailing list
>>>>> >> >> L2Ork-dev at disis.music.vt.edu
>>>>> >> >> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > --
>>>>> >> > Dr. Albert Gr"af
>>>>> >> > Computer Music Research Group, JGU Mainz, Germany
>>>>> >> > Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>>> >> > _______________________________________________
>>>>> >> > L2Ork-dev mailing list
>>>>> >> > L2Ork-dev at disis.music.vt.edu
>>>>> >> > https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>> >> _______________________________________________
>>>>> >> L2Ork-dev mailing list
>>>>> >> L2Ork-dev at disis.music.vt.edu
>>>>> >> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Dr. Albert Gr"af
>>>>> > Computer Music Research Group, JGU Mainz, Germany
>>>>> > Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>>> > _______________________________________________
>>>>> > L2Ork-dev mailing list
>>>>> > L2Ork-dev at disis.music.vt.edu
>>>>> > https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>> _______________________________________________
>>>>> L2Ork-dev mailing list
>>>>> L2Ork-dev at disis.music.vt.edu
>>>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>
>>>>
>>>>
>>>> --
>>>> Dr. Albert Gr"af
>>>> Computer Music Research Group, JGU Mainz, Germany
>>>> Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>> _______________________________________________
>>>> L2Ork-dev mailing list
>>>> L2Ork-dev at disis.music.vt.edu
>>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>
>>> _______________________________________________
>>> L2Ork-dev mailing list
>>> L2Ork-dev at disis.music.vt.edu
>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>
>>
>>
>> --
>> Dr. Albert Gr"af
>> Computer Music Research Group, JGU Mainz, Germany
>> Email: aggraef at gmail.com, web: https://agraef.github.io/
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> https://disis.music.vt.edu/listinfo/l2ork-dev
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev



-- 
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/20200925/62bce4b1/attachment.html>