[osg-users] osgViewer Cocoa and wxOSX/Cocoa Application
Dear OSGlers, is there a obvious way to tell osgViewer (Cocoa version of recent trunk) to leave the menubar alone? I guess the code is still experimental - so would it be possible to add this functionality? Attached a screenshot that shows the result of combining wxOSX (Cocoa) and a standard osgViewer::Viewer (also Cocoa). This was part of my investigation into updating my application. GUI toolkit is done in wxWidgets, rendering osg - I actually wanted to get the viewer integrated with the GUI again, not separate like in the image attached. A few observations: 1) using wxOSX (2.9 configure flag --with-osx_cocoa) and trunk of osg compiled with Cocoa viewer - method with GraphicsWindowCocoa - I derived from GraphicsWindowCocoa::WindowData and set the NSView to the one retrieved from my underlying control (wxControl derived) - the result is a window ~64x64 in the left top corner, regardless of the constructor flags I set. - method with setUpViewerAsEmbeddedInWindow - the canvas ends up somewhere on the screen whole application gets stuck - I tried to use either timerbased or idleloop based update via _viewer-frame() - method with external viewer: see attached image, the menubar gets unusable - method with GraphicsCanvas (derived from osgviewerWX) - mixed bag, I get an occasionally stuck GUI. For instance MenuItems don't highlight but can be selected. 2) using wxOSX (2.9 configure flag --with-osx_carbon) and branch 2.8 of OSG (carbon viewer) - GraphicsCanvas seems the only way to get it working proper I had to swap harddrive yesterday and went the whole plunge for SL - fighting now with STL problems reported earlier - I can't seem to be able to load files in Release but all works fine in Debug (this is for OSG 2.8 combined with wxWidgets 2.8) - it almost feels like Visual Studio now - sigh :( Cheers, Hartmut -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZattachment: wxOSX_OSG_trunk.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer Cocoa and wxOSX/Cocoa Application
Hi Hartmut, li...@technotecture.com schrieb: is there a obvious way to tell osgViewer (Cocoa version of recent trunk) to leave the menubar alone? I guess the code is still experimental - so would it be possible to add this functionality? Attached a screenshot that shows the result of combining wxOSX (Cocoa) and a standard osgViewer::Viewer (also Cocoa). This was part of my investigation into updating my application. GUI toolkit is done in wxWidgets, rendering osg - I actually wanted to get the viewer integrated with the GUI again, not separate like in the image attached. A few observations: 1) using wxOSX (2.9 configure flag --with-osx_cocoa) and trunk of osg compiled with Cocoa viewer - method with GraphicsWindowCocoa - I derived from GraphicsWindowCocoa::WindowData and set the NSView to the one retrieved from my underlying control (wxControl derived) - the result is a window ~64x64 in the left top corner, regardless of the constructor flags I set. GraphicsWindowCocoa is the one who creates the NSView. You pass a windowdata with the flags CreateOnlyView to the constructor and after the GraphicsWindowCocoa is constructed you can query the NSView from the WindowData via getCreatedNSView() and add it to your NSWindow / NSView. For this method you'll have to create your window (or load it from a nib-file) yourself. Here's a small snippet: osgViewer::GraphicsWindowCocoa::WindowData* wdata = new osgViewer::GraphicsWindowCocoa::WindowData(osgViewer::GraphicsWindowCocoa::WindowData::CreateOnlyView); osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits(); traits-x = 0; traits-y = 0; traits-width = 800; traits-height = 600; traits-inheritedWindowData = wdata; traits-doubleBuffer = true; traits-sharedContext = 0; traits-vsync = true; // create graphics context osg::ref_ptrosgViewer::GraphicsWindowCocoa gc = dynamic_castosgViewer::GraphicsWindowCocoa*(osg::GraphicsContext::createGraphicsContext(traits.get())); NSView *view = wdata-getCreatedNSView(); // Mainview is the main-view of the window ... [mainview addSubview: view]; // add the view created by GraphicsWindowCocoa to the main-view If you want a NSWindow containing only one NSView, use the GraphicsWindowCocoa with a GraphicsWindowCocoa::WindowData(0), then GraphicsWindowCocoa does not create the app-specific stuff and returns the window only. You can get the NSWindow-reference via GraphicsWindowCocoa::getWindow() To recap the three options: CreateOnlyView: GraphicsWindowCocoa creates only the view (a NSOpenGLView) and store it in the WindowData-class (no window, nada) CheckForEvents: osgViewer queries the system for new events and handles them (mimicking the Cocoa event loop) . If you are using a real cocoa app which installs an event loop, you don't want this. PoseAsStandaloneApp: osgViewer constructs a standard menubar and installs some handler for it and some other stuff. If you are using a real cocoa app which handles the menubar automagically, you don't want this. - method with setUpViewerAsEmbeddedInWindow - the canvas ends up somewhere on the screen whole application gets stuck - I tried to use either timerbased or idleloop based update via _viewer-frame() I have no experience with setUpViewerAsEmbeddedInWindow but to my knowledge you'll have to manage the OpenGLContext (make current, swap, etc) by yourself - method with external viewer: see attached image, the menubar gets unusable see my previous notes about WindowData(0) - method with GraphicsCanvas (derived from osgviewerWX) - mixed bag, I get an occasionally stuck GUI. For instance MenuItems don't highlight but can be selected. You'll have to be careful which thread handles the events. Mac OS X does not like, if you handle events on another thread than the main-thread. Perhaps WindowData(0) is your friend here, too. Hope this helps Cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer Cocoa and wxOSX/Cocoa Application
Thanks Stephan, for the explanation - I will see if I can make this work with wxWidgets trunk. Cheers, H On Thu, 08 Oct 2009 01:06:31 +0200, Stephan Huber ratzf...@digitalmind.de wrote: Hi Hartmut, li...@technotecture.com schrieb: is there a obvious way to tell osgViewer (Cocoa version of recent trunk) to leave the menubar alone? I guess the code is still experimental - so would it be possible to add this functionality? Attached a screenshot that shows the result of combining wxOSX (Cocoa) and a standard osgViewer::Viewer (also Cocoa). This was part of my investigation into updating my application. GUI toolkit is done in wxWidgets, rendering osg - I actually wanted to get the viewer integrated with the GUI again, not separate like in the image attached. A few observations: 1) using wxOSX (2.9 configure flag --with-osx_cocoa) and trunk of osg compiled with Cocoa viewer - method with GraphicsWindowCocoa - I derived from GraphicsWindowCocoa::WindowData and set the NSView to the one retrieved from my underlying control (wxControl derived) - the result is a window ~64x64 in the left top corner, regardless of the constructor flags I set. GraphicsWindowCocoa is the one who creates the NSView. You pass a windowdata with the flags CreateOnlyView to the constructor and after the GraphicsWindowCocoa is constructed you can query the NSView from the WindowData via getCreatedNSView() and add it to your NSWindow / NSView. For this method you'll have to create your window (or load it from a nib-file) yourself. Here's a small snippet: osgViewer::GraphicsWindowCocoa::WindowData* wdata = new osgViewer::GraphicsWindowCocoa::WindowData(osgViewer::GraphicsWindowCocoa::WindowData::CreateOnlyView); osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits(); traits-x = 0; traits-y = 0; traits-width = 800; traits-height = 600; traits-inheritedWindowData = wdata; traits-doubleBuffer = true; traits-sharedContext = 0; traits-vsync = true; // create graphics context osg::ref_ptrosgViewer::GraphicsWindowCocoa gc = dynamic_castosgViewer::GraphicsWindowCocoa*(osg::GraphicsContext::createGraphicsContext(traits.get())); NSView *view = wdata-getCreatedNSView(); // Mainview is the main-view of the window ... [mainview addSubview: view]; // add the view created by GraphicsWindowCocoa to the main-view If you want a NSWindow containing only one NSView, use the GraphicsWindowCocoa with a GraphicsWindowCocoa::WindowData(0), then GraphicsWindowCocoa does not create the app-specific stuff and returns the window only. You can get the NSWindow-reference via GraphicsWindowCocoa::getWindow() To recap the three options: CreateOnlyView: GraphicsWindowCocoa creates only the view (a NSOpenGLView) and store it in the WindowData-class (no window, nada) CheckForEvents: osgViewer queries the system for new events and handles them (mimicking the Cocoa event loop) . If you are using a real cocoa app which installs an event loop, you don't want this. PoseAsStandaloneApp: osgViewer constructs a standard menubar and installs some handler for it and some other stuff. If you are using a real cocoa app which handles the menubar automagically, you don't want this. - method with setUpViewerAsEmbeddedInWindow - the canvas ends up somewhere on the screen whole application gets stuck - I tried to use either timerbased or idleloop based update via _viewer-frame() I have no experience with setUpViewerAsEmbeddedInWindow but to my knowledge you'll have to manage the OpenGLContext (make current, swap, etc) by yourself - method with external viewer: see attached image, the menubar gets unusable see my previous notes about WindowData(0) - method with GraphicsCanvas (derived from osgviewerWX) - mixed bag, I get an occasionally stuck GUI. For instance MenuItems don't highlight but can be selected. You'll have to be careful which thread handles the events. Mac OS X does not like, if you handle events on another thread than the main-thread. Perhaps WindowData(0) is your friend here, too. Hope this helps Cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
