[L2Ork-dev] Purr Data 2.14.2 - ALT key

Albert Graef aggraef at gmail.com
Thu Sep 24 21:35:39 EDT 2020


On Thu, Sep 24, 2020 at 8:31 PM Linux ROUEN Normandie <linux.rouen at free.fr>
wrote:

> - Strange thing when back to the patch where [pd subpatch] is located,
> it switched automatically from editmode to runmode. Normal or not?
>

The engine still thinks that it's in temporary runmode. Just press and
release Alt once again in the parent patch and you'll see that you're still
in editmode (the grid will come back). The reason is that the subpatch
which pops up gets the Alt keyup, not the parent patch canvas which waits
for it.

In fact, that's the one residual issue from the long list of regressions
that we had with the Ctrl keybinding previously. So in fact we need
Jonathan's solution (sketched out in the other 2.14.2 thread) even with Alt
for this one specific case.

Joseph, it would be nice if you could report this as a ticket on the issue
tracker so that we don't forget about it, thanks!

* Linux Mint 20.0 (Ubuntu 20.04)
> - In editmode: ALT + click on [pd subpatch] does not open it but well
> blinds the new grid. I never tested with CTRL, so I cannot compare.
>

This does work for me on Manjaro, 100% reliably. I suspect that it's
because Alt-Click is remapped by your desktop environment. Alt-drag *is*
mapped to move-window in many DEs. On Manjaro, I have this function
remapped to the Windows key modifier in KDE/Plasma, so I don't have that
issue. I believe that it's possible in most DEs to configure the modifier
for that mouse action, so probably there's a way that you can work around
that issue.

Yeah, that wouldn't happen if we'd still be using Ctrl, would it? I can
hear Jonathan's triumphant "Told you so!" in my brain now. Along with the
evil laughter of Dr. No. ;-)

So now, I do need to fix this big joke before being able to test Purr
> Data 2.14.2 under this distribution.
>

No need to test on Manjaro, I'm testing Purr all the time there, as that
distro is my daily driver.

* ALT vs CTRL vote
> I don't care about either as long as it's making its job and the
> developers life easier.
>

Ok, abstention, so that vote doesn't tip the scale either way. Thanks.

>From the developers' POV, Alt is certainly the easier solution, I think
that even Jonathan agrees with me on that. From the UX POV, we'd like to
keep Ctrl obviously, for backward and vanilla compatibility, but I'd still
argue that it's not a great idea to use the same modifier key that's also
being used for all the menu keybindings.

If I counted correctly, there's no clear decision yet, so are there any
more votes? Or is everyone else on this mailing list agnostic about the
issue?

Albert

-- 
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/084bb70e/attachment.html>


More information about the L2Ork-dev mailing list