[L2Ork-dev] Purr Data 2.14.2

[Albert Graef]

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? :)

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. 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. :)

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200924/ddd2c519/attachment-0001.html>