@robliou said in QML Button onClicked() - cannot open Dialog/PopUp until function finishes?:
@jeremy_k
Hello Jeremy, thank you for taking the time to reply.
So far, this sounds like the expected behavior. The Qt event loop is blocked as long as application code is running in the UI thread.
OK, makes sense, but surely when i run progressBarDialog.open() this isn't blocking the GUI event loop, or is it? Isn't opening a dialog/ popup just a local event?
I don't know what's meant by a local event. In my toy test on macOs, Dialog.open() followed by a long-running operation still shows the dialog before becoming unresponsive. I don't know that this is required by the interface. It's not inconceivable to me that some windowing systems might require a working event loop to show a window.
toy.qml:
import QtQuick.Window
import QtQuick.Dialogs
Window {
visible: true
MessageDialog { id: dialog }
MouseArea {
anchors.fill: parent
onClicked: {
console.log("pre");
dialog.open();
for (var i = 0; i < 500000000; i++)
;
console.log("post");
}
}
}
Secondly, the fact that I used QThread to run run_function should mean that a new thread is now running this function, so there should be no interference with the GUI event loop?
It shouldn't interfere with the C++ event loop implementation. There will be contention for any python code run in an event handler, slot, etc.
This is the interesting part. Is the Widgets implementation more or less free of python code? If so, this is the expected behavior. If not, or perhaps regardless, a comparison could be fruitful.
I took another look at my QT Widgets code on how I achieved proper functioning.
I'm lost in the description. If you can share a terse, brief example, that might help. If not, it sounds like you understand the Python and Qt widgets fundamentals.
@robliou said in QML Button onClicked() - cannot open Dialog/PopUp until function finishes?:
I suspect that QML, not Python, is causing the problem. The GUI locks when you try to both do something in the main GUI event loop (i.e. open a QML popup window) and also run a Python function, as triggered from a QML event (i.e. clicking a button). QML seems to automatically lock the main event loop, even if the Python function is called using a separate thread.
Native code that is run from python (PySide and PyQt included) need to explicitly drop the global interpreter lock to allow other python threads to execute. It's possible that you've found a defect where this release is missing. The QML engine itself isn't likely to be involved. While a signal handler/QML event is running, that QML engine is blocking its thread's event loop.
If you can put together a minimal example, that would help for a bug report. And as usual, try the latest release to verify that the issue hasn't already been addressed.
