Hi Julian, For further submissions could you please send whole files rather than patches. I've looked through the patch by hand and it's not in a state that suitable for merging - breaking all build on all platforms except yours isn't acceptable so another solution will need to be found.
As a general note, I'm confused by the mixing of X11 and Carbon. Is Qt built against X11 or Carbon? If Qt is built against X11 then you'll need to select the X11 build for OSG as well. My guess is that the Qt example might need to have some CMake code in it to direct the example to compile different paths. Robert. On Thu, Nov 6, 2008 at 5:03 AM, Julian Scheid <[EMAIL PROTECTED]> wrote: > Hi folks, > > sorry - sent this to the wrong list, here it is again. > > In the meantime realized that the WindowData change (2nd chunk in patch for > examples/osgviewerQT/QOSGWidget.cpp) won't compile outside of OS X. Not > sure what the best solution is, could do an ifdef in QOSGWidget.cpp or, > maybe better, change Carbon WindowData to carry an HIViewRef instead of a > WindowPtr - though I don't know the implications of that. If you'd let me > know how you want to deal with this I'm happy to send an updated patch. > > Cheers, > > Julian > > > ---------- Forwarded message ---------- > From: Julian Scheid <[EMAIL PROTECTED]> > Date: Sun, Nov 2, 2008 at 6:38 PM > Subject: Re: Shadows in osgviewerQT ? (solved / patch) > To: [EMAIL PROTECTED] > > > Hi again, > > please find attached a patch against current trunk that fixes my problems. > > This patch does the following (in order of the chunks in the patch): > > - Add a missing include in GraphicsWindowsX11 without which it won't compile > on my Mac. > - Add a missing include to the osgviewerQt build (taken straight from > src/osgviewer/CMakeLists.txt) > - Ensure GraphicsWindowsCarbon::WindowData is used with QOSGWidget for Mac > builds even on 10.4 and 10.5. Without this change, the widget will use the > X11 WindowData struct but the peer will expect a Carbon WindowData struct, > leading to a segfault. I'm not sure this is the right fix - it might have to > pay attention to other configure-time variables. (I.e. it might not work if > you asked for using the X11 peers instead of the carbon peers at configure > time) > - Extract a WindowPtr from the HIViewRef that QWidget::winId() returns. > Without this change, the peer tries to call GetWindowPort on the HIViewRef > which returns 0. This was the reason that the window remained white. > - Setup the camera only after ViewerQOSG's Qt base class has been > initialized. Without this change, the view is wrong (doesn't cover the whole > window). > - Open the ViewerQOSG window at 30/30 instead of 0/0. When opened at 0/0 it > lacks any window decoration (not sure why that is so - might be a Qt > "feature"?) > > I hope this helps. > > Cheers, > > Julian > > On Fri, Oct 31, 2008 at 12:26 PM, Julian Scheid <[EMAIL PROTECTED]> > wrote: >> >> Hi, >> >> OK so I figured out that my problems are due to using AdapterWidget - I >> understand that shadows etc. should work fine with QOSGWidget. >> >> Unfortunately QOSGWidget doesn't work here: the widgets remains white and >> Qt prints warnings about recursive repaint. >> >> I've checked out the latest OSG trunk and tried with that but get the same >> result (actually it segfaults due to a bogus ifdef in the QOSGWidget source >> code - I'll send over a patch shortly - but after fixing that I get the same >> result.) >> >> I've started tracking down the problem, so far the only thing that I >> figured out is that GetWindowPort always seems to return 0 for the >> QOSGWidget's native peer - is that expected? >> >> I'm using Qt 4.4.3 on an Intel Mac with OS X 10.5. The Carbon code paths >> are used, not X11. Are there any known problems with QOSGWidget with Qt >> 4.4, OS X 10.5 or with the Carbon peers? >> >> Thanks in advance, >> >> Julian >> >> >> On Thu, Oct 30, 2008 at 3:30 AM, Julian Scheid <[EMAIL PROTECTED]> >> wrote: >>> >>> Hi, >>> >>> I'm trying to embed osg in a Qt4 application. I've had some troubles with >>> FSAA/multisampling but managed to work around it by configuring the >>> QGLWidget for FSAA instead of osg. >>> >>> However, I'm now trying to get shadows to work based on the osgshadow >>> code, and it seems that no matter which shadowing technique I try it brings >>> my machine to a grinding halt - the whole screen starts to flicker wildly, >>> circles and balls reminiscent of Katamari Damacy are drawn into the scene, >>> and when continuous update (via timer) is enabled I have no recourse but to >>> restart my machine. (This is one of the new Intel Macbooks running OS X >>> 10.5) >>> >>> I gather that when embedded in Qt, the GraphicsWindowCarbon code isn't >>> used and osg just uses the existing GL context. Does that mean that I would >>> have to manually setup Qt's GL context and somehow synchronize it with osg's >>> shadow magic? >>> >>> If all that is meant to be supported in the Qt viewer, is there any >>> chance you could add an example for this situation? >>> >>> Thanks in advance, >>> >>> -Julian >>> >> > > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
