[L2Ork-dev] Purr Data 2.14.2

[Jonathan Wilkes]

On Wed, Sep 23, 2020 at 11:33 PM Albert Graef <aggraef at gmail.com> wrote:
>
> On Wed, Sep 23, 2020 at 11:12 PM Mario Sottile - Marionetas Mey <mariomey at gmail.com> wrote:
>>
>> ...but I don't understand why the change. Why MrAnderson?
>
>
> Who's MrAnderson? :)

That's what Agent Smith calls Neo in the movie The Matrix.

>
> Anyway, this change was the easiest way to solve some serious bugs in the GUI, such as the Ctrl+F shortcut for the findbox not working. Try Ctrl+F to search for an object in 2.13.0 and you'll see what I mean.
>
> The root cause of all of these problems was the double binding of the Ctrl key as temporary run mode key and modifier for all our menu keybindings. This caused essentially two issues:
>
> - First, the mouse cursor (and, now that we have it, the grid) "flashing" in edit mode, i.e., a brief switch to the run mode cursor (and no grid) whenever you invoke one of the menu shortcuts such as Ctrl+S (Save). You can even see the former in vanilla Pd if you watch carefully. There it's only the mouse cursor flashing into and out of run mode again, which is easy to ignore. But the problem was aggravated by the introduction of the edit mode grid, which for now is just an edit mode indicator and positioning aid, and you can easily turn it off in the GUI preferences. So this is mostly a cosmetic issue.
>
> - Second, and much more seriously, invoking *any* kind of menu operation keybinding which pops up some kind of dialog, such as Ctrl+Shift+S (Save as), or that ominous Ctrl+F (Find), would break edit mode synchronization between engine and GUI. That is, the GUI would still (incorrectly) think that it's in temporary run mode, while the engine correctly switches back into edit mode as soon as the Ctrl key goes up again.

> The root cause of this is that in our JS-based GUI toolkit, the Ctrl key up event would then register only in the popup dialog, but never be propagated to the rest of the GUI.

If the backend successfully switches back to edit mode, then by
definition the GUI is correctly sending a <ctrl> keyup event to the
backend. Because that's the only thing which should trigger that
switch.

Upon receiving that keyup event, the backend sends a message to the
GUI to switch to edit mode. This backend->GUI message should be the
*only* way the GUI switches to/from edit mode.

So I don't think I understand the root cause of the bug.

> Vanilla Pd apparently doesn't have that problem because it uses a different toolkit (Tcl/Tk).
>
> Changing the temporary run mode key binding so that it no longer interferes with our menu key bindings was the easiest (and IMHO the only proper) way to resolve those issues. While it may be possible to work around these bugs *without* changing the temporary run mode key, that would always be a kludge and incur a substantial amount of technical debt going forward. At least that's my opinion.
>
> We had some heated discussion about this, as we are all acutely aware of the woes and wtfs this change will cause to seasoned Pd users. But in the end it was decided to just do it that way, and add that little warning to help users to become aware of the change. It shouldn't be more difficult to get accustomed to this than, say, switching between the different modifier keys of Linux/Windows and Mac.
>
> I still maintain that this *is* the right way to resolve that key binding conflict, both from a technical and a UX point of view. If enough users complain about it, we may have to change it back to what it was. But that means that someone will have to figure out how to work around these bugs in another way, probably with some awful kludges and a lot of duct tape. ;-)
>
> Ok, I hope that this clears things up a bit. I think that we should maybe have a quick show of hands so that we can see who wants the ctrl key back, and who is ok with the alt key. Cast your votes please. :)

I vote for keeping the <ctrl> binding.

-Jonathan

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