[L2Ork-dev] Purr Data 2.14.2

Albert Graef aggraef at gmail.com
Fri Sep 25 15:26:11 EDT 2020


On Fri, Sep 25, 2020 at 8:51 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> No, this works for me.


Thank goodness! I was getting afraid that we were going to open that whole
can of worms again. ;-)


> I mean, if we get a huge user revolt we can revisit it.
>

Sure. I hope that this won't happen, though.

It's a bummer our first reporter on this didn't notice the
> compatibility message to the console. I'd suggest focusing the console
> for it, but I'm afraid that will trigger yet another dangling `<ctrl>`
> error. :)
>

LOL. :) Maybe we should at least print that message in red (or some other
color) to make it stick out more?

Albert


> -Jonathan
>
>
>
>
> >
> > Albert
> >
> >
> > On Fri, Sep 25, 2020 at 6:16 PM Albert Graef <aggraef at gmail.com> wrote:
> >>
> >> 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/
> >
> >
> >
> > --
> > 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/de0ed418/attachment-0001.html>


More information about the L2Ork-dev mailing list