I haven't been using QT&SFML integration for a few months and today I've realised my previous code stopped working, most likely after updating to SFML 2.4 (from 2.3.2).
#include <SFML/Graphics/RenderWindow.hpp>
#include <QApplication>
#include "mainwindow.h"
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
sf::RenderWindow app((sf::WindowHandle) w.winId()); //Code stops here
return a.exec();
}
It just stops, no error message or anything. Can anybody test it on SFML 2.4.0 & Qt 5.7 and some other versions?
Here's code of MainWindow class, most likely not useful at all.
//mainwindow.h
#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QMainWindow>
namespace Ui {
class MainWindow;
}
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
explicit MainWindow(QWidget *parent = 0);
~MainWindow();
private:
Ui::MainWindow *ui;
};
#endif // MAINWINDOW_H
//mainwindow.cpp
#include "mainwindow.h"
#include "ui_mainwindow.h"
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
}
MainWindow::~MainWindow()
{
delete ui;
}
Okey, I recently found some time to look into this. The problem does NOT occur on SFML 2.3.2, not at all. I recompiled it and with the exact same Qt version it's ok. Also, it isn't a problem with my library only, any other way to get SFML render to Qt doesn't seem to work. Here's an other topic describing this problem: http://en.sfml-dev.org/forums/index.php?topic=21070.0 (http://en.sfml-dev.org/forums/index.php?topic=21070.0)
As drawing to native widget is an SFML feature (is it?), should I mark it as an issue on github?
//edit:
Here's backtrace:
//edit2:
Recompiled SFML 2.4.0 in debug mode; more precise backtrace.
#0 0x00007ffff5d57780 in recvmsg () at /usr/lib/libc.so.6
#1 0x00007ffff451aba7 in () at /usr/lib/libxcb.so.1
#2 0x00007ffff451b4d8 in () at /usr/lib/libxcb.so.1
#3 0x00007ffff52d4b89 in () at /usr/lib/libX11.so.6
#4 0x00007ffff52d4cfb in () at /usr/lib/libX11.so.6
#5 0x00007ffff52d4fed in _XEventsQueued () at /usr/lib/libX11.so.6
#6 0x00007ffff52b1bfb in XCheckIfEvent () at /usr/lib/libX11.so.6
#7 0x00007ffff79323d7 in sf::priv::WindowImplX11::processEvents() (this=0xadc020) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Unix/WindowImplX11.cpp:603
#8 0x00007ffff79337b2 in sf::priv::WindowImplX11::setVisible(bool) (this=0xadc020, visible=true) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Unix/WindowImplX11.cpp:928
#9 0x00007ffff79359b4 in sf::priv::WindowImplX11::initialize() (this=0xadc020) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Unix/WindowImplX11.cpp:1607
#10 0x00007ffff7931905 in sf::priv::WindowImplX11::WindowImplX11(unsigned long) (this=0xadc020, handle=37748752) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Unix/WindowImplX11.cpp:413
#11 0x00007ffff792a52f in sf::priv::WindowImpl::create(unsigned long) (handle=37748752) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/WindowImpl.cpp:78
#12 0x00007ffff7929ac2 in sf::Window::create(unsigned long, sf::ContextSettings const&) (this=0x7fffffffe170, handle=37748752, settings=...) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Window.cpp:141
#13 0x00007ffff74dfc69 in qsf::QSFMLWidget::showEvent(QShowEvent*) () at /usr/lib/libQSFML.so.1
#14 0x00007ffff6e1cef8 in QWidget::event(QEvent*) () at /usr/lib/libQt5Widgets.so.5
#15 0x00007ffff6dd5e0c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#16 0x00007ffff6ddd581 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#17 0x00007ffff6831de0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5
#18 0x00007ffff6e19b28 in QWidgetPrivate::show_helper() () at /usr/lib/libQt5Widgets.so.5
#19 0x00007ffff6e1c945 in QWidget::setVisible(bool) () at /usr/lib/libQt5Widgets.so.5
#20 0x0000000000403e1a in main ()
//edit3:
Apparently it's all because of sf::Window trying to get events by itself (backtrace #7). It didn't work earlier either, but didn't cause anything like that. However there's no documented way to remove events handling without modifying SFML code. Maybe adding sf::RenderWindow::enableEventProcessing(bool) set to true by default would be good idea? Or some fix in backend, maybe it's all caused by some small mistake in code.