Paul Shabash schrieb: > We've figured it out. > > It's due to this code fragment in GraphicsWindowCarbon.cpp, > OSXCarbonWindowSystemInterface::OSXCarbonWindowSystemInterface() 356-9: > > // register application event handler and AppleEventHandler to get > quit-events: > static const EventTypeSpec menueventSpec = {kEventClassCommand, > kEventCommandProcess}; > OSErr status = InstallEventHandler(GetApplicationEventTarget(), > NewEventHandlerUPP(ApplicationEventHandler), 1, &menueventSpec, 0, NULL); > status = AEInstallEventHandler( kCoreEventClass, kAEQuitApplication, > NewAEEventHandlerUPP(QuitAppleEventHandler), 0, false); > > It basically just dumps any Quit handlers that have been installed before. > > Isn't this a rather dangerous thing to do? The code should check for any > pre-existing handlers and chain them if there are any.
To my knowledge you can add more than one application-/event-handler, so this should be safe. It might that the event-handler itself behaves badly. But with your setting I thinkt the best way is to add no event handlers at all, because Qt handles all the application-setup. I have no experience with Qt and the carbon-implementation misses some implementation details (e.g. using it in another carbon-app) but feel free to add the missing functionality and submit it back to osg-submission. I don't know if you can mix Cocoa with QT, then perhaps the new Cocoa backend in 2.9.x might be useful, as there is some functionality to bypass the application-setup stuff. Or just create a subclass from osg::GraphicsContext::WindowingInterface which doesn't setup the carbon-app-stuff, and just returns GraphicsWindowCarbon-/PixelBufferCarbon-instances and register this class via osg::GraphicsContext::setWindowingInterface() cheers, Stephan _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org