SFML community forums
Help => General => Topic started by: Skomakar'n on July 13, 2010, 08:33:52 pm
-
I have managed to get a Qt window with an SFML view integrated into it compiling and booting up perfectly fine; the problem is that the widget which is supposed to hold the SFML render viewport is completely blank.
It does work to create the SFML window separately, as a window of its own. It will update, clear to the right colour and render the sprite that I have told it to draw, but when using the Create() member function with the inherited winId() function from QWidget as its argument, after having to do a reinterpret cast to sf::WindowHandle *, or otherwise it won't compile, the widget is left blank.
I can't figure out what's wrong. Please help.
I've put everything I have so far on Pastebin:
main.cpp (http://pastebin.com/KFPbvkBd)
classes/SFML/Viewport.h (http://pastebin.com/v0NcWaa8)
classes/SFML/Viewport.cpp (http://pastebin.com/YhY9fcHT)
classes/GUI/MainWindow.h (http://pastebin.com/ed2Z6TRX)
classes/GUI/MainWindow.cpp (http://pastebin.com/5tT0sfsa)
-
Did you try first the Qt sample from the SFML SDK?
-
Did you try first the Qt sample from the SFML SDK?
My code is based on that code. I'm not missing out on anything that's been done there.
I guess I could add that I'm on Mac OS X Snow Leopard.
-
Which version of SFML do you use?
-
Which version of SFML do you use?
SFML 1.6 and Qt 4.6.
-
sf::WindowHandle is void*, so you should try to cast winId() into sf::WindowHandle, not sf::WindowHandle*.
-
That doesn't make any difference (and it doesn't make any sense to me to cast to a non-pointer either).
-
That doesn't make any difference
Ok, then I can't help more, you should see with Ceylo (I don't know if he's aware of this topic). I know that he worked a lot in SFML 1.6 to make the Qt integration work better.
and it doesn't make any sense to me to cast to a non-pointer either
??
sf::WindowHandle is void*
-
That doesn't make any difference
Ok, then I can't help more, you should see with Ceylo (I don't know if he's aware of this topic). I know that he worked a lot in SFML 1.6 to make the Qt integration work better.
All right. Thanks. I'll throw him a PM.
and it doesn't make any sense to me to cast to a non-pointer either
??
sf::WindowHandle is void*
Ah! Sorry. I misinterpreted.
-
From what I remember, you cannot import Qt windows with SFML because OpenGL needs some specific window attributes. And these attributes are not used by Qt (and cannot be set after window creation).
Maybe you noticed a "invalid drawable" message in your console, and I believe that's why you can only see a blank widget.
Thus... the only thing you can do is separating the SFML window from the Qt stuff : make a SFML window for your drawing, and other windows for the Qt stuff.
-
From what I remember, you cannot import Qt windows with SFML
Wasn't it supposed to work in 1.6 after your last modifications?
-
Nah. With the 1.6 modifications, you can import a Cocoa window or a Cocoa view (widget). And the object returned by Qt is a Cocoa view. But I can't do anything if the parent Cocoa window hasn't been created with the correct attributes (which is the problem with Qt).
-
Nah. With the 1.6 modifications, you can import a Cocoa window or a Cocoa view (widget). And the object returned by Qt is a Cocoa view. But I can't do anything if the parent Cocoa window hasn't been created with the correct attributes (which is the problem with Qt).
Do you know which attributes are correct?
-
The window device creation must not be defered. This is done by passing "NO" as latest argument of -[NSWindow initWithContentRect:styleMask:backing:defer:].
Edit: see the NSWindow class documentation (http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/occ/instm/NSWindow/initWithContentRect:styleMask:backing:defer:)
-
Isn't that Objective-C stuff? I'm using C++.
-
Cocoa is in Objective-C, and Qt uses Cocoa to do the GUI stuff, as SFML does for the Mac OS X port.
Even if you only see the C++ SFML classes, the SFML windows
are created through Cocoa.
-
Cocoa is in Objective-C, and Qt uses Cocoa to do the GUI stuff, as SFML does for the Mac OS X port.
Even if you only see the C++ SFML classes, the SFML windows
are created through Cocoa.
So how can I possibly make it work? I'm using qmake with G++, for C++, for this. I've manually edited the makefile to tell G++ that I'm using the SFML frameworks.
-
I already told you.
Thus... the only thing you can do is separating the SFML window from the Qt stuff : make a SFML window for your drawing, and other windows for the Qt stuff.
There is no other solution for now.
-
I already told you.
Thus... the only thing you can do is separating the SFML window from the Qt stuff : make a SFML window for your drawing, and other windows for the Qt stuff.
There is no other solution for now.
Aw... Do tell when you've fixed it.
-
I'm sorry to disappoint you but I'm no more working on the Mac OS X port. This will have to be done by the next developers.
Besides, this is not really something you can fix on SFML's side. The only possibilities I could think of are : modify Qt source code to change the defering parameter, or wait for Apple to drop this limitation.