<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 24, 2020 at 8:31 PM Linux ROUEN Normandie <<a href="mailto:linux.rouen@free.fr">linux.rouen@free.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- Strange thing when back to the patch where [pd subpatch] is located, <br>
it switched automatically from editmode to runmode. Normal or not?<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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!<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

* Linux Mint 20.0 (Ubuntu 20.04)<br>
- In editmode: ALT + click on [pd subpatch] does not open it but well <br>
blinds the new grid. I never tested with CTRL, so I cannot compare.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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. ;-)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So now, I do need to fix this big joke before being able to test Purr <br>
Data 2.14.2 under this distribution.<br></blockquote><div><br></div><div>No need to test on Manjaro, I'm testing Purr all the time there, as that distro is my daily driver.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

* ALT vs CTRL vote<br>
I don't care about either as long as it's making its job and the <br>
developers life easier.<br></blockquote><div><br></div><div>Ok, abstention, so that vote doesn't tip the scale either way. Thanks.</div><div><br></div><div>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.</div><div><br></div><div>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?<br></div><div><br> </div><div>Albert<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" target="_blank">https://agraef.github.io/</a></div></div></div></div></div></div></div>