SFML community forums
General => General discussions => Topic started by: denismr on August 25, 2011, 04:52:01 am
-
Hi.
I'm a new user of both SFML and Qt and I had some troubles when I tried to make their integration.
I'm using Qt 4.7.4 and SFML 1.6.
I got the code of SFMLCanvas in the tutorial page (http://www.sfml-dev.org/tutorials/1.6/sources/QSFMLCanvas.hpp) and I have noticed that it's necessary to modify showEvent method, exchanging the line "Create(winId());" for "create();"
The OnUpdate method is being called, but it doesn't draw anything and doesn't even fill the canvas with the clear color.
void QAnimationPlayer::OnUpdate() {
Clear(sf::Color(0, 255, 0, 255));
sf::Shape line = sf::Shape::Line(sf::Vector2f(0,0),sf::Vector2f(200,200),20.f,sf::Color(255,0,255));
Draw(line);
std::cout << "I'm here\n";
std::flush(std::cout);
}
Is qt integration on Mac OS X unsupported?
Sorry me for orthographic mistakes. English isn't my native language.
Thank you.
-
exchanging the line "Create(winId());" for "create();"
This breaks the code. You must call the Create function from sf::RenderWindow. But I don't know if this is supposed to work with SFML 1.6 on OS X. Maybe it was not implemented or not working well.
-
I saw this comment in the code of wxWidget integration:
// Tested under Windows XP only (should work with X11
// and other Windows versions - no idea about MacOS)
Does it mean that integrating SFML to a GUI on OS X is currently possible only under Cocoa (or under direct X11, since OS X supports X11 applications in a compatibility mode)?
I was planning to write a program compatible with Windows and Mac OS.
Thank you
-
DirectX11 and X11 are two very different things. X11 is a window system för Unix systems.
-
DirectX11 and X11 are two very different things. X11 is a window system för Unix systems.
I know it.
I just forgot to put a sad smile at the end of my last line ( Cocoa and X11 aren't functional to my objective).
-
Only Ceylo knows if SFML 1.6 can work this way with Qt. I know he worked hard on it before 1.6 was released, but I don't remember if everything was ok.
-
DirectX11 and X11 are two very different things. X11 is a window system för Unix systems.
Why not für? :lol:
For these who don't know Swedish or German: both Swedish "för" /føːr/ and German "für" /fyːɐ̯/ mean "for".
-
SFML 1.6 does work with Qt as soon as you use the Cocoa version of Qt. But I don't know whether it works with the default samples.
I'll tell you if I can get it to work as soon as I've got Qt downloaded (should be within 45min).
-
Ok, it doesn't seem to work out of the box.
First I had to replace the Qt includes with QtCore and QtGui so that the Qt headers can be found. Then... for some reason QSFMLCanvas::paintEvent(QPaintEvent*) doesn't get called. I don't exactly know why, but I remember that when I had wanted to use Qt, I had set up a timer function called every 1/60 sec to do the drawing stuff. Then it had worked. Fixing the reason why paintEvent() doesn't get called may also fix the problem.
You may also experience a crash when exiting your Qt application. If this occurs, I'll tell you what to do, it's just a one line fix because of the memory management of Qt conflicting with SFML's one.
-
@Ceylo
Thank you for the clarifications.
I'm going to try something in this sense tomorrow and then I post the results here.
-
I've read a little and I've discovered some interesting things.
Since an old version of Qt (I think that it's the 4.5) was released, Cocoa is the default for 64bit architectures.
The winId method returns different types depending on which API is currently being used.
For the old versions of Qt that use Carbon instead of Cocoa, the return value is a HIViewRef, and it's possible to recovery the WindowHandle (needed by Create) from it using the method HIViewGetWindow.
But this doesn't work when Qt is using Cocoa. In this case, winId returns a NSView and I still don't know how to recovery an WindowHandle from it.
I'll search more as soon as I have free time.
-
The SFML 1.x port has been made so that you can import both NSWindow and NSView objects. Thus the id returned by winId() is fine. The point here is rather about OpenGL drawing : it does not happen.
-
The SFML 1.x port has been made so that you can import both NSWindow and NSView objects. Thus the id returned by winId() is fine. The point here is rather about OpenGL drawing : it does not happen.
That's kinda sad.
I actually plan to make an sprite animation editor (as a part of a complete tool set) for a friend of mine (we are working on a project in our (short) free time and he draws well).
I already made one editor in 2010, in Java, for turning a homework easier, but it's simpler than what I need by now and it would be perfect if I don't mix the languages. This is why I want to use Qt (my friend uses Windows and I use Mac OS X and Linux).
-- off topic
For curiosity, the homework (for OOP classes in the uni) was a short game. I (and another friend) put in it some graph theory, vectorial collision check, punctual physics and the editor was useful only for making one animation: the explosion. The hurry was so big that we didn't make the physics right (we skipped the conservation of energy, entrusting the visual physical effect to the friction, what didn't work well, but we were very out of time. At least the collision check worked out). There were other problems too. Until that time, we didn't have CG classes and we didn't apply affine transformations correctly for the coordinates manipulation. =p
That's a video:
http://www.4shared.com/video/G-HkFttX/filme.html?
-- on topic
Back to the topic: I don't know if I should spend time trying to fix it. I have absolutely no experience with Qt and I can say the very same about my experience with SFML.
I really would love to do it, but my schedule is unbelievably impracticable: algorithm programming contest (ICPC), a lot of classes (8:00am -> 7:00pm) , scientific initiation (technical reports)...
Is there any alternative for integrating the GUI that works on Mac and on Windows?
Thank you very much for helping me.
-
Have you tried SFML 2? There's no point working on SFML 1.6, it's not maintained anymore and SFML 2 will be released in a few weeks.
-
I don't understand why you said it's sad, the only point is that the drawing method doesn't get called.
-
for some reason QSFMLCanvas::paintEvent(QPaintEvent*) doesn't get called. I don't exactly know why, but I remember that when I had wanted to use Qt, I had set up a timer function called every 1/60 sec to do the drawing stuff.
Hmm, this is exactly what is done in the QSMLCanvas class. There's a timer which triggers the pain event (otherwise it's called only when the widget needs to be repainted -- which means never if nothing happens).
-
Yup, but for some reason the method doesn't get called even for the first draw, and I don't know why and I don't have time to spend on it now.
-
for some reason QSFMLCanvas::paintEvent(QPaintEvent*) doesn't get called. I don't exactly know why, but I remember that when I had wanted to use Qt, I had set up a timer function called every 1/60 sec to do the drawing stuff.
Hmm, this is exactly what is done in the QSMLCanvas class. There's a timer which triggers the pain event (otherwise it's called only when the widget needs to be repainted -- which means never if nothing happens).
Exactly! The way to call the paintEvent method is calling repaint method, and nothing happens when I do it manually (and the QSFMLCanvas already does it with its timer).
And it's only possible to draw through this method (before someone says, the attribute WA_PaintOutsidePaintEvent isn't supported on Mac and Windows).
I still think that the problem is in how I'm using Create method.
The QSFMLCanvas like it's distributed doesn't even is compiled, and if that line is commented, the repaint works but (obviously) nothing is drawn.
(For compiling, I was naively casting the return value of winId and when I do so, the paintEvent isn't called).
I didn't find the method that gets an WindowHandle from a NSView yet. I'm going to google it and maybe the problem will be solved.
-
(For compiling, I was naively casting the return value of winId and when I do so, the paintEvent isn't called).
Casting a pointer to another kind of pointer is fine.
I didn't find the method that gets an WindowHandle from a NSView yet. I'm going to google it and maybe the problem will be solved.
-[NSView window]
But this is an Objective-C method, not C++, thus you'd need to use Objective-C++ to be able to use both (and change the file name extension to .mm instead of .cpp).
Besides, as already said, SFML 1.6 for Mac DOES support importing NSView object, thus the above is useless. If import didn't work, you would get an error message.
PS: and drawing outside of the paint event, even if I can't tell whether it's safe, did work for me, without specifying any attribute.
-
(For compiling, I was naively casting the return value of winId and when I do so, the paintEvent isn't called).
Casting a pointer to another kind of pointer is fine.
I didn't find the method that gets an WindowHandle from a NSView yet. I'm going to google it and maybe the problem will be solved.
-[NSView window]
But this is an Objective-C method, not C++, thus you'd need to use Objective-C++ to be able to use both (and change the file name extension to .mm instead of .cpp).
Besides, as already said, SFML 1.6 for Mac DOES support importing NSView object, thus the above is useless. If import didn't work, you would get an error message.
PS: and drawing outside of the paint event, even if I can't tell whether it's safe, did work for me, without specifying any attribute.
Please, how did you draw outside the paint event? Did you just call the SFML methods like Clear, Draw, etc?
I tried this and nothing happens =/ .
-
http://www.sfml-dev.org/forum/viewtopic.php?p=37163#37163
I just called the paintEvent() method through a timer. I did not change the contents of the method.
-
http://www.sfml-dev.org/forum/viewtopic.php?p=37163#37163
I just called the paintEvent() method through a timer. I did not change the contents of the method.
Did you passed null as parameter (QPaintEvent*), since it isn't used? I tried this as well (and it still doesn't work).
Edit:
when you did so, were you using qt 3.x?
-
Don't do that, Qt has a well defined system for painting, based on the paintEvent which is triggered automatically whenever needed and/or by a call to repaint() (or update(), I don't remember).
If the paintEvent is never triggered, make sure that you have a QApplication running (ie. an event loop -- QtGui cannot run without it).
-
Don't do that, Qt has a well defined system for painting, based on the paintEvent which is triggered automatically whenever needed and/or by a call to repaint() (or update(), I don't remember).
If the paintEvent is never triggered, make sure that you have a QApplication running (ie. an event loop -- QtGui cannot run without it).
As I said in this post
http://www.sfml-dev.org/forum/viewtopic.php?p=37247#37247
paintEvent isn't called even when I manually call repaint() method and I'm sure that the QApplication is running.
-
I agree with Laurent, it's better to find out why the method doesn't get called. I had done this timer thing because I needed a quick and working demo.