0

独自のスレッドから pyqtSignal#emit() 呼び出しを正常にトリガーする python ファイルシステム (ウォッチドッグ) コードがあります (pdb トレースによって証明されています)。

このシグナルは、connect(...) を介して自分の QObject の対応する @pyqtSlot 関数に接続する必要がありますが、実際には、ファイルシステムの変更が発行をトリガーするときにターゲット関数が呼び出されることはありません。

サンプル コードは、 https://github.com/cefn/xmlorgmode/blob/2b97ff9994132def035d325fc7f7095c9fe187f2/index.pyで確認できます。

同じフォルダーから渡された XML ファイルと XQuery ファイルを使用して、次のように呼び出すことができます。

python index.py index.xml index.xq

これは初めて完全に読み込まれますが、ファイルシステムによってトリガーされたときに更新が行われることはありません。これは、コードが機能した場合に期待されることです。失敗は沈黙です。

ウォッチドッグによってトリガーされた発行が QueryDisplay#update(...) の呼び出しに対応するために必要な追加のイベントループ構造を誰かが提案できますか?

バックグラウンド

私は動的に構築された HTML を、時折変更されるフォルダー内のテキスト ファイルに裏打ちされた QWebView に渡す実験を行ってきました。QWebView#setHtml(...) は独自のスレッド内で呼び出される必要があるため、シグナルとスロットを見つけ出さなければならず、レンガの壁にぶつかりました。私がたどり着いた糸通しの配置はどういうわけか壊れていますが、その方法がわかりません。

QObject を適切なスレッド内のイベント ループに関連付けて、発行されたものを処理できるようにする方法を確立できません。実行中のコードをデバッグした後、app.exec_() ループに入る直前に #thread() を pdb と対話的に呼び出してアフィニティを確立すると、QApplication、QWebView、および私の QObject はすべて同じスレッドを共有します。これは、これらすべてのオブジェクトのすべてのイベントが app.exec_() 内で処理されることを意味すると思っていましたが、何らかの形でモデルを誤解していたに違いありません。

(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>
4

1 に答える 1

0

これは PEBKAC でしたが、少なくとも 2 つの興味深い機能の相互作用がありました。基本的に、emit() は実際にスロットをトリガーしていましたが、トリガーを監視するために行ったすべての試みには欠陥がありました。

まず第一に、PDB はブレークポイントがメイン スレッドで発生しない場合、単純に無視します。これらのコード行が実際に実行されたとしても、別のスレッドで発生した場合はトリガーされません。これは非常に悪いニュースですが、さらに悪いことに、サイレント エラーです。回避策は、デバッガー シェルを使用するのではなく、PDB をインラインで呼び出すようにコードを手動で変更することですが、そのような方法では、デバッガーで制御の流れを調査するという目的が無効になります。このため、ブレークポイントが設定されていても、実際に呼び出しが行われるのを確認できませんでした。

第 2 に、QXMLQuery は自動的にファイルとキャッシュへの変更を静かに無視するため、再起動され、基になる「フォーカス」ファイルが実際に変更された場合でも、変更は無視されます。このため、トリガーされたインタラクションの結果を確認できませんでした (キャッシュによって変更が表示されませんでした)。

于 2014-12-18T12:50:05.793 に答える