Details
-
Bug
-
Resolution: Done
-
P3: Somewhat important
-
5.6.2, 5.7.0
-
None
-
Debian unstable
Description
I have a program which disables user inputs at some point to be able to queue them for later. This works fine till I try to show a file dialog (see the attached sample), which (simplified) boils down to:
MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow) { ui->setupUi(this); connect(ui->pushButton, &QPushButton::clicked, []() { QEventLoop* loop = new QEventLoop; QTimer::singleShot(1000, [loop]() { QFileDialog::getOpenFileName(qApp->activeWindow(), "test", "/tmp"); loop->quit(); loop->deleteLater(); }); loop->exec(QEventLoop::ExcludeUserInputEvents); }); }
This seems to work on windows but fails horribly on Linux with Glib (window does not paint properly nor reacts to user input). Since QFileDialog internally uses a new eventloop which does not exclude user inputs, I do not understand why this happens. Is this a bug in Qt, are nested event loops like that just not supported, or…? I do realize that my usage here is kinda odd, but I do not see why it could not work.
Attachments
Issue Links
- relates to
-
QTBUG-59760 Calling QEventLoop::exec(ExcludeUserInput) causes a busy loop with 100% CPU usage on glib
- Closed
-
QTBUG-49770 Native Gtk2 file dialog (and possibly any other native dialog) can come up in a broken state when opened after a QCoreApplication::processEvents(QEventLoop::ExcludeUserInputEvents) call.
- Closed