thanks geoffroy! cc @redFrik

Thank you @geoffroymontel ! I won't be able to look at this for few days but I'd love to eventually - unless others get to it first :)

I can confirm this prevents the crash when pressing cmd+q.

Not sure if it would be in the scope of this PR, but the SC GUI window still can't be closed with cmd+w (#4309). Would adding cmd+w to close the GUI window be a possible addition and in the scope of this PR?

BTW should we write cmd+q or cmd-q, or all caps CMD+Q?

Thanks for reviewing !!

I can confirm this prevents the crash when pressing cmd+q.
Cool !

Not sure if it would be in the scope of this PR, but the SC GUI window still can't be closed with cmd+w (#4309). Would adding cmd+w to close the GUI window be a possible addition and in the scope of this PR?

Mmm, it's quite different. Could you file a new issue with this feature request please ?

Best

Mmm, it's quite different. Could you file a new issue with this feature request please ?

#4309 is already filed, is this what you had in mind?

Yes, it is. @geoffroymontel can you please fix that? Check the build log for the details.

@brianlheim sorry for that, it's fixed now !

going through 3.10.4 changes for the changelog, i'm a bit confused by this one -- if cmd+q is supposed to quit the interpreter, why is it bad that the interpreter would quit with this shortcut? is this a regression from earlier behavior somehow?

see #3824 (comment)

i'm not sure whether in the past cmd-q was supposed to quit the interpreter on macos. i think it's mainly that this can be confusing for beginners and doesn't offer much benefit for experienced users. someone else can probably answer this more fully though, i'm now also a bit confused myself.

it also looks like the bug report in #3824 is a full-blown segmentation fault, not a graceful exit, but maybe someone could answer to what the behavior was before the crash (assuming that it was a regression).

It is (was?) a regression. And yes, the issue was that this was a segfault instead of a graceful exit.

In 3.8, when the interpreter got a separate icon, cmd-q was not triggering shutdown (no action) when interpreter was in focus. This seems to be the desired behavior. At some point this changed to segfault, which is definitely a regression. This PR restores the behavior from 3.8.

For reference, in the cocoa days, and before the interpreter had a separate icon, there was no concept of shutting it off by itself. With either the editor or a gui window cmd-q would quit everything - editor, interpreter (and by extension the server). In practice, if one was in the middle of working on code with unsaved changes, any accidental cmd-q would prompt "save changes?" dialog, preventing accidental shutdown.
In short, cmd-q should not shut down the interpreter by itself. It should either not do anything (behavior with this PR), or possibly attempt shutting down the IDE (which would be closer to the cocoa SC behavior). But I really believe with this PR we have the desired behavior.

thanks for the explanation.

there is a lot of "convention over configuration" keybindings happening in sclang gui, which i'm not a huge fan of. what if someone isn't using the IDE, and actually does want cmd+q to quit the interpreter?

I think supporting cmd+q to quit the interpreter causes more harm than benefits ! I don't see a practical use case for it. Removing it at least solves a few annoying bugs (like pressing cmd+q on a user Window during a performance would kill the interpreter).

there is a lot of "convention over configuration" keybindings happening in sclang gui, which i'm not a huge fan of. what if someone isn't using the IDE, and actually does want cmd+q to quit the interpreter?

I just checked - cmd+q is propagated like any other key combination to the views in the QT GUI. So user still has the option to implement quit if desired.