[mac] Need a way to differentiate Cmd-Q from closing window(s) [$500 awarded]

[Flamefork]

Common pattern for apps is to hide on window close but quit on Menu->Quit (Cmd-Q).

Currently, Quit menu item calls closeAllWindows, thus triggering close event for each window. There seems to be no straight way to distinguish between this two events.

The $500 bounty on this issue has been claimed at Bountysource.

[Flamefork]

Probably just switching from closeAllWindows to quit is not a good approach, cause there would be no way to do any shutdown work.
One possible solution is to trigger some special quit event in addition to closeAllWindows call. Probably the better solution is to implement some general gracefulQuit App method that works similar to window close.

[Flamefork]

I would work on this, but need some help on approach for this.

[tommoor]

Just hit this issue myself, I can make the app hide when clicking on the close button as many OSX apps do, but unfortunately I get the same behaviour when hitting CMD+Q.

Ideally the window 'close' event would pass some sort of parameter with it to signify where the event came from, currently there is no parameter passed into the callback, so this could be done with backwards compatibility.

@zcbenz - noticed you did the work on this area previously - thoughts?

[timoxley]

anyone figure this out?

[tommoor]

Would still love to see this tackled, seems like a fairly quick win from an outside perspective.

[hugorodrigues]

+1

[theabraham]

👍

[tommoor]

@rogerwang any thoughts on this one? particularly useful in Mac apps as the different close types usually perform slightly different actions. I.e on most apps clicking the red cross minimises to the dock instead of hard quitting.

[tommoor]

@rogerwang in most usecases the expected behaviour of clicking on the red menubar button is that the application should minimize. With NW the app completely quits, simply passing some sort of parameter to know which way exit was triggered would (dock, menubar, shortcut) would allow us to handle this correctly.

thoughts?

[rogerwang]

Will fix this in 0.8.4

[timoxley]

🎉

[wengqianshan]

thx!

[hugorodrigues]

[petejkim]

@rogerwang quitting from dock still does not seem to send "quit" event

[hugorodrigues]

@rogerwang @petejkim yup, dock quit still not triggering :(
Please check #924

[tommoor]

I can't help but wonder if this would be better just having a parameter on the exit event that tells you which of the places its being triggered from:

• Menu
• Dock
• Window
• Shortcut

It's then upto the developer to choose whether the app should close in those situations? As some apps will want to close with the window and others not...

[Flamefork]

@tommoor +1

[petejkim]

@rogerwang please reopen this issue.

[tommoor]

Just another bump, personally feel like this should have more priority as it's basic window management :'(

[adam-lynch]

👍

[hugorodrigues]

+1

[timoxley]

👍 👍

[rogerwang]

the fix is merged and can be tried with http://dl.node-webkit.org/live-build/09-17-2014/mac64_master-build-187-4ab12b7-a2233c1-55a6ed5-ac542a9-1ce8544-86728d1/node-webkit-v0.10.6-pre-osx-x64.zip

[tommoor]

@rogerwang @mrfabbri do you have an outline of the final solution, how should we handle this?

[rogerwang]

@tommoor yeah. we'll find a way to distinguish the source of the closing as you suggested. Please file another issue for it, perfectly with some API suggestions.

[tommoor]

@rogerwang I just don't understand what this fix does, how does it close the issue? Thanks!

[rogerwang]

@tommoor the subject of the original report is lost, so I thought it was about NW should send an event when user tries to quit from dock.

[rogerwang]

@tommoor I'm a little confused by what the issue is really about, because people are suggesting different things. Since you put the bounty on this issue, is your requirement exactly the comments you left on Jan 6? Do you have any suggestions on the API?

[tommoor]

Yes, as comments on Jan 6th. It comes down to the fact that on Mac some applications quit entirely when you click on the red button whilst others simply hide (usually communications/media apps like ours).

I'd suggest making this similar to other events in Javascript, perhaps an event passed to the window close callback (good for future proofing). You could use the currentTarget property or a new property to avoid confusion eg 'source':

var win = gui.Window.get();
win.on('close', function(ev) {
  console.log("You tried to close the app from the " + ev.source);

  if (ev.source != "window") {
    win.close(true);
  }
});

[tommoor]

@rogerwang is that helpful? Personally wishing this will get fixed before Yosemite public release as we currently have a fake title bar built in CSS to get around this problem 😱

[rogerwang]

@tommoor when will be the public release? Currently we are focused on our deadline to catch Chrome 38 release with NW11, but I will try to fix this before that.

[tommoor]

@rogerwang now in GM (Gold Master) status, next release is public which will be before the end of the month, likely around three weeks.

http://www.macworld.co.uk/news/mac-software/mac-os-x-yosemite-release-date-launching-soon-features-uk-price-3493748/

[mrfabbri]

Hi @tommoor, 33c1255 fix the quit from dock (and also hitting cmd+q while cmd+tabbing) so that the app does not terminate immediately and windows on close handlers are properly called (with 'quit' as the event parameter) .

In the v0.10.6-pre-osx-x64 version @rogerwang posted earlier in the thread you can try something like:

var gui = require('nw.gui');
var win = gui.Window.get();

win.on('close', function(event) {
  if (event == 'quit') {
    win.close(true);
  } else { 
    // event is `undefined`
    win.hide();
  }
});

gui.App.on('reopen', function() {
  win.show();
});

Right now the close event differentiates (only) between

• a quit "request" from menu, dock, shortcut (with 'quit' as the event parameter being passed to the close handler) and
• a close "request" from the window (with no event parameter -i.e. undefined- being passed to the close handler). Maybe a 'window' parameter would provide a clearer distinction from the other case.

By using NSApplication.currentEvent inside applicationShouldTerminate it should be possible to find out the source of the termination request (dock, menu, ...) and pass a proper parameter to nw::App:CloseAllWindows() which should be modified (along with ShouldCloseWindow in Shell and the NativeWindowDelegate) to accept a parameter (enum? int?) other than the bool quit. What is your opinion @rogerwang on this?

That said, I think most of the use cases are having a simple differentiation between the close window versus quit application and the further differentiation for dock, menu should not hinder this simple case, i.e. being able to tell if (event = 'quit') { ... } independently from the source of the quit event.

[tommoor]

@mrfabbri appreciate the clarification. I'll give this a blast on the pre-release as soon as I can 😄

[tommoor]

@mrfabbri @rogerwang I can confirm this works for the usecase, we should make sure to document this well 😃

Lets close this bad boy!

[ghostoy]

@rogerwang Will there be a 0.10.6 release later?

[tommoor]

Hey @mrfabbri could you claim or decline the bounty on this issue? If you don't want it I would like to redistribute the money to some other issues in this repo that need solving 😄

[mrfabbri]

claimed! 😄

[tommoor]

My pleasure ;-) thanks!

On Tue, Nov 18, 2014 at 11:48 AM, Marco Fabbri [email protected]
wrote:

claimed! 😄

Reply to this email directly or view it on GitHub:
#430 (comment)

[tommoor]

@rogerwang this can be closed.

[varshneyjayant]

Thanks guys! this saved my day :)