After some more research into the issue I have found the following description which sounds familiar.
http://www.cocoabuilder.com/archive/cocoa/235068-nsapplication-appleevent-and-cfrunloop-source-strange-interaction.html > It is working nicely, except for the quit sequencing. In Linux/GTK, the > analogous mechanism is installing the read end of a pipe using > g_io_add_watch, writing to the pipe when a message is posted to my framework, > and it works perfectly. > > For the Cocoa implementation, I have implemented an > applicationShouldTerminate app delegate notification handler which posts a > quit request to my framework (triggering it by way of the CFRunLoopSource) > and returns NSTerminateCancel. That last detail is very unfortunate, but if > I return NSTerminateLater the app goes into a modal state and neglects the > CFRunLoop, with my framework's quit request not being received as a > consequence. ... > It's not neglecting the run loop. It's just running it in a different > mode. The documentation for NSTerminateLater says it's running it in > the NSModalPanelRunLoopMode. So, just add your run loop source in > that same mode, in addition to the default mode. Then, you can use > NSTerminateLater and all of your headaches vanish. > > Cheers, > Ken In Racket gui-lib "mred/.../cocoa/.../queue.rkt" line 264 adds the source via socket but I don't know how to recreate the solution in that way with the "new" modal run loop in the applicationShouldTerminate implementation. I especially can't tell which interactions there might be with the polling pumping system which I do not completely understand. HTH nonetheless Il giorno 21/mag/2015, alle ore 06.50, Michael Tiedtke ha scritto: > > Il giorno 20/mag/2015, alle ore 16.44, Matthew Flatt ha scritto: > >> It's been a few years since I last looked at this. If I remember >> correctly, the problem is a mismatch between the `racket/gui` model of >> eventspaces and the way that shutdown notifications and responses work >> in Cocoa. The mismatch makes it difficult for `racket/gui` to defer its >> answer to the OS while performing further GUI activity that might >> involve events and/or threads. > > https://developer.apple.com/library/mac/documentation/Cocoa/Reference/NSApplicationDelegate_Protocol/index.html#//apple_ref/occ/intfm/NSApplicationDelegate/applicationShouldTerminate: > > >> >> The `applicationShouldTerminate:` handler is in >> >> gui-lib/mred/private/wx/cocoa/queue.rkt >> >> While it may appear that returning `NSTerminateLater` is the solution, >> I think that would leave Cocoa still driving the event loop, which >> locks out Racket from changing threads (because it's not safe to change >> Racket threads while Cocoa is on he stack), and so on. > > Is it really on the stack? I don't believe Cocoa's run loop does really exist > as such, others say > it has to do with the speed of sonic waves or windows but in fact there is a > message > passing protocol defined: NSApplicationDelegateProtocol > https://developer.apple.com/library/mac/documentation/Cocoa/Reference/NSApplicationDelegate_Protocol/index.html#//apple_ref/occ/intfm/NSApplicationDelegate/applicationShouldTerminate: > > NSTerminateLater changes the mode of the run loop to NSModalPanelRunLoopMode > which should work like [when showing] any other modal dialog. > > Eventually the application should answers with > replyToApplicationShouldTerminate. > > Perhaps when someone really needs to ask the user ot wants to autosave sth > before > quitting than one migh try to operate from within that single thread event > with the Cocoa > thingy on the stack. > > BTW a subclass of dialog% may look like a modal dialog but clicking in the > parent > window changes focus. Well, it doesn't change completely but I get a > kcg-warning > about the focus and I can access the menu of the parent window again. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
