Command Q to quit on Mac OS X

[tomaka]

Original: rust-windowing/glutin#468

Not sure if still relevant.

[mitchmindtree]

Just tested the window example on OS X 10.10.5 and can confirm CMD+Q does not quit (or print any special events). Not sure if that's still something we'd want to handle in winit - I imagine we did, we'd at least still want some way to handle the request to close the window.

[repi]

Can confirm that this is still the case; CMD+ Q on Mac doesn't quit or close the window.

One can easily add it oneself though by checking VirtualKeyCode::Qand modifiers.logo, which is what I've done.

But would be nice if it was automatic in Winit and generate WindowEvent::Closed, but no big deal.

[francesca64]

With the new CloseRequested behavior, implementing this would be (functionally) pretty innocuous, though I don't believe it's a good precedent to set.

[ryanisaacg]

I've been using winit (through glutin) and I was wondering if it would be appreciated if I tried to add this behavior (personally it feels inconsistent that I can request a close through Alt+F4 on Windows but not through CMD+W or CMD+Q on Mac)

[francesca64]

I suppose that there's not any case where Cmd+Q shouldn't trigger CloseRequested, since it's not like winit's goal is to support making horribly non-compliant applications. So, if you want it, then feel free to add it, and I'll merge it.

[francesca64]

Actually, Cmd+Q shouldn't send CloseRequested, but a new top-level QuitRequested variant or something, shouldn't it?

[ryanisaacg]

I'm not too sure; I'm pretty new to the Mac world. That definitely sounds right though.

[ghost]

on Mac, closing a window (or pressing cmd+W is pretty ubiquitously interpreted as "hide the program but do not end the process". cmd+Q on the other hand usually means "please end the process". programs often ask if you want to save, etc., in response to cmd+Q.

imo, the tricky thing here is that the behavior (in response to closing the window, or Alt+F4) is kind of mixed on Windows and Linux. some programs end their process and others simply hide. however, it seems like the "default" behavior on the Windows and Linux side is to exit completely.

i'm not sure what all this currently looks like in winit, but i agree with francesca. a separate QuitRequested value should be defined. i think any solution that can support all of the above behaviors should be fine.

[francesca64]

QuitRequested could also be useful for handling alacritty/alacritty#675

[Osspial]

Reviving this issue from the dead: FWIW, I'm against adding new events to Event or WindowEvent that only ever get implemented on a single platform, since it makes it unlikely that those events will actually get used downstream. Would it be reasonably compliant to have cmd+Q send a CloseRequested event to every window in the application?

[ryanisaacg]

@Osspial CMD+Q should also kill any background processes for the application, but I'm not sure how in-scope for Winit that is. I think sending a close to all windows would come the closest to getting the "correct" behavior.

[Osspial]

@ryanisaacg I mean, if all of an application's windows are closed there isn't a whole lot you can sensibly do besides terminate the entire application and its children.

[tomjakubowski]

I mean, if all of an application's windows are closed there isn't a whole lot you can sensibly do besides terminate the entire application and its children.

On Mac OS, it's long been common for applications to stay open after all windows close, because of the menu bar's persistence outside of any window's lifetime.

For example, in a simple word processor, where a window corresponds to an open document, a user may close all of their documents and then want later to create a new document or open an existing one. It's possible (even likely) they'd leave the application running with no open windows, then switch to it, probably using the Dock, and finally select the appropriate thing from the menu bar to open a new window.