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
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
