Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML 2 and Qt 5  (Read 6025 times)

0 Members and 1 Guest are viewing this topic.

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
SFML 2 and Qt 5
« on: January 15, 2016, 01:41:47 pm »
Hi everybody!

As the title suggest I am trying to set up SFML and Qt to work together. I know this has been done before and I am probably just being stupid somewhere, but I ran into some issues. I couldn't find a complete example/template that uses recent versions of SFML or Qt. Thats why I thought I just ask here.

So here is my code. It is of course based on Elias Dalers awesome project and the existing wiki page. I pushed my code into a repo to make it easier to download.

(click to show/hide)

As you can see in the screenshot most of the stuff is already working. The weird part I am having trouble with is that some events do not reach in the SFML window event loop. For example I do receive MouseButtonReleased and Resized events, but I can't get any MouseWheelScrolled or KeyReleased events. Does anybody have a clue why thats happening?
Also I can't connect the button to a function, but I think thats an unrelated problem. Still if somebody knows why that would be a great help.

Here is the error output when the program is run:
(click to show/hide)

I hope that somebody how has more experience with Qt and SFML working together can help me figure this out.
Maybe we can put it on the wiki once its working. I am sure it can be useful to other people in the future as well.

Thanks in advance,
Foaly

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: SFML 2 and Qt 5
« Reply #1 on: January 15, 2016, 06:24:17 pm »
There was a time... long ago... when Qt and SFML would just work fine alongside each other. Then came this thing called XCB. First, Qt decided to base its Qt5 implementation on XCB instead of Xlib. This isn't that bad as long as you use Qt by itself. As soon as you start using Qt with anything else that uses Xlib instead or expects Xlib to be used (like the Nvidia optimus port), things start to fall apart.

SFML isn't/wasn't much different when 2.3 was released. We migrated almost fully to XCB. Only in retrospect did we notice that it might not have been such a great idea. While in theory XCB is supposed to be "better" than Xlib in many ways, in practice it is far from that. This is mostly because XCB was, is and probably never will be completed. There are many features that Xlib supports that are planned in the XCB roadmap, but because it is an open source project and people lost interest, they will probably never get implemented. 2 of the main missing features are the interface to the OpenGL driver (GLX) and Unicode keyboard input. This led to that "broken phase" between SFML 2.3 and 2.3.2. For 2.3.2, I reverted back to Xlib event handling, since it is more or less tried and true and simply "worked". The SFML code is currently in a state where both Xlib and XCB are used. XCB where it can be used without problems and Xlib where XCB just isn't good enough.

If you are wondering how Qt coped with XCB, just have a look at their platform code base. There are several "hacks" built in at the critical places. They always took care of Unicode keyboard input manually themselves, so this isn't a problem for them. Because SFML isn't such a huge library and we really don't want to bloat the code base with unnecessary workarounds, we'll just stick with Xlib for now.

The reason why you are having issues getting Qt5 and SFML to play nice together is because of all of the above. Qt5 uses the XCB event queue and SFML currently uses the Xlib event queue again. There are some things that were hacked into Xlib event handling (such as the Unicode keyboard input) that have no equivalent in XCB. Conversely, there are some things Qt5 does with its XCB event queue that don't map to the Xlib event queue.

Qt5 was probably never made with interoperation with other windowing libraries in mind, otherwise they would have probably stuck to Xlib. This might also be the reason why they don't mind introducing hacks where they are due either. It is sad that something that used to work no longer does, but quite honestly, if you are going to use Qt5, you might as well go the whole nine yards and use it without SFML. Besides being able to use SFML's lightweight abstractions, there aren't really that many benefits from using them together. Qt does everything SFML does and much more, just with a different API.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

shadowmouse

  • Sr. Member
  • ****
  • Posts: 302
    • View Profile
Re: SFML 2 and Qt 5
« Reply #2 on: January 15, 2016, 06:37:59 pm »
So is it possible to use QT5.5 with SFML doing just rendering to a GraphicsScene and not using SFML for events?

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: SFML 2 and Qt 5
« Reply #3 on: January 15, 2016, 06:59:08 pm »
You can't separate event handling and OpenGL drawing. They are tightly coupled together on Linux. DRI expects buffer swap events to come its way from GLX when we decide to swap buffers (when you call .display()). If it works, great. However, there is no guarantee that it will always work flawlessly on all distributions/hardware.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

shadowmouse

  • Sr. Member
  • ****
  • Posts: 302
    • View Profile
Re: SFML 2 and Qt 5
« Reply #4 on: January 15, 2016, 07:13:25 pm »
That's a shame. I've got lots of my course work done with sfml and I'm much more familiar with drawing stuff with sfml, but the application ends up looking much more professional and being easier to use with a Qt gui, so I guess I'll have to redo all my drawing code using Qt.  :-\

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: SFML 2 and Qt 5
« Reply #5 on: January 15, 2016, 07:31:19 pm »
If you are willing to pull off some really weird looking (platform-specific) stuff, you can get SFML and Qt to share their OpenGL contexts with each other. This would let you use an sf::RenderTexture's texture to draw a "full-screen" textured quad in Qt and do the actual drawing in SFML itself. This is a bit tricky to pull off, but entirely possible.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

shadowmouse

  • Sr. Member
  • ****
  • Posts: 302
    • View Profile
Re: SFML 2 and Qt 5
« Reply #6 on: January 15, 2016, 07:41:19 pm »
Ooooh, that's an interesting idea. I'll try that if I can't work out how to easily replicate my SFML code using Qt.

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: SFML 2 and Qt 5
« Reply #7 on: January 17, 2016, 01:14:43 pm »
Oh man that sucks...  :(
So just a quick summery to make sure I understood it correctly. There is no way to get Qt and SFML working together out of the box on Linux, because of the XCB Xlib event handeling incompatiblity. Seperating rendering and event handling won't work either, because rendering relies on event handeling (like you said buffer swapping in .display()) The only way around would be to hack the libraries to share their OpenGL context, right?

One follow up question: You were talking about linux here, but I experience the problem I described on windows (win 8.1 mingw gcc 4.8.1). Is that related somehow?

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: SFML 2 and Qt 5
« Reply #8 on: January 17, 2016, 01:47:48 pm »
So just a quick summery to make sure I understood it correctly. There is no way to get Qt and SFML working together out of the box on Linux, because of the XCB Xlib event handeling incompatiblity. Seperating rendering and event handling won't work either, because rendering relies on event handeling (like you said buffer swapping in .display()) The only way around would be to hack the libraries to share their OpenGL context, right?
Yes.

One follow up question: You were talking about linux here, but I experience the problem I described on windows (win 8.1 mingw gcc 4.8.1). Is that related somehow?
No. If you can get it to work on Windows without these problems, there is a slight chance it might work on some Linux distributions. There is no guarantee however that it will work on all distributions.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).