Qt World Summit: Register Today!

[SOLVED] Signals/Slots not properly bound to an event dispatching loop - Newbie silliness, can you help?

  • I have python filesystem (watchdog) code successfully triggering a pyqtSignal#emit() call from its own thread (proven by a pdb trace).This signal is wired via connect(...) to a corresponding pyqtSlot-annotated function, but the target function is in fact never called when a filesystem change triggers the emit().

    I'm certain it's a very basic error I'm making, but having looked at quite a lot of Qt widget-oriented slot and signal examples, I can't see what I've done wrongly.

    The example code can be inspected at https://github.com/cefn/xmlorgmode/blob/2b97ff9994132def035d325fc7f7095c9fe187f2/index.py

    and can be invoked as follows, with the XML file and an XQuery file passed in from the same folder in github if anyone needs to actually run it.

    @python index.py index.xml index.xq

    This loads the result of the XQuery perfectly into the QWebview the first time, but no refresh ever takes place (triggered by changes to index.xml or index.xq in the filesystem), which is what I would expect if my code worked. The filesystem changes are detected, and emit() fires, but no update() is called. Failure is silent.

    Can anyone suggest the additional event loop structures which I need for the emit() to trigger the call to QueryDisplay#update(...) ?


    I've been experimenting with passing dynamically constructed HTML to QWebView backed by text files in a folder which change occasionally. Because of the requirement that QWebView#setHtml(...) is called within its own thread, I've had to try and figure out signals and slots, and I've hit a brick wall. The threading arrangement that I've arrived at is somehow broken but I can't figure out how.

    I cannot establish how my QObject is supposed to be associated with an event loop within the appropriate thread so that things emitted from my QObject can get handled. Having debugged the running code, the QApplication, QWebView and my QObject all share the same thread when calling #thread() interactively with pdb to establish affinity, just before entering the app.exec_() loop. I thought this would mean that all eventing for all these objects would be handled within app.exec_() but I must have misunderstood the model somehow.

    @(Pdb) adaptor.thread()
    <PyQt4.QtCore.QThread object at 0xb30c3c44>
    (Pdb) display.view.thread()
    <PyQt4.QtCore.QThread object at 0xb30c3c44>
    (Pdb) app.thread()
    <PyQt4.QtCore.QThread object at 0xb30c3c44>@

    For reference I'm running python-qt4 4.9.3-4 on Debian Wheezy running Gnome3, although I hope this is irrelevant.

  • This was the result of two interlocking features of the tools I was using.

    First of all PDB breakpoints seem to be locked to the thread they were inserted from. Consequently, because the QT Eventing thread was the one triggering the update, PDB wasn't able to detect the invocation.

    Secondly, QXMLQuery seems to have inbuilt caching, meaning that changes to focus and query files had no impact on the second invocation of evaluateToString()

    Between these two features, it meant that I was unaware that update WAS in fact being called. After building a minimal test case, I was able to track down the problems.

Log in to reply