[L2Ork-dev] Purr Data 2.14.2

[Albert Graef]

On Fri, Sep 25, 2020 at 2:57 AM 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 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.
>

Or maybe not. On second thought, I think that we want to give immediate
visual feedback when the user enters temp runmode, especially now that we
have the editmode grid. If we defer that until actually clicking something,
that doesn't provide immediate feedback any more. This is true no matter
whether Ctrl or Alt is the modifier.

Now we may be able to fudge that by just handling the visual feedback on
the spot in the GUI as soon as the user presses the temp runmode key. But
if we return to Ctrl that means that we still have that annoying flashing
of the grid whenever the user presses Ctrl to enter a menu shortcut. Look
at it any way you like, if we want to give immediate visual feedback for
temp runmode (and I think we should), then having Ctrl bound to that
function is just more trouble than it's worth. Vanilla can get away with
that only because it hardly provides any visual cues in that case and hence
there's no such flashing effect (other than the cursor changing shape,
which is easy to ignore).

It's really a tricky issue. All in all, I think that the switch to the Alt
key provides the cleanest solution, because it eradicates most of these
annoying side-effects in one fell swoop. There's still the issue that
Joseph reported, with Alt-click not exiting temporary runmode after opening
a subpatch. But I think that this is a minor bug which can actually be
fixed by Jonathan's first method (sending a fake Alt keyup in the
corresponding click handler). This will be *much* easier than having to
fake those keyups in every single menu handler that may invoke a popup, so
I think that I'll be able to implement this by myself without too much
difficulty. I'll look into that next.

Albert


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


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