0

gtk.TreeStore (pyGTK 2.10) の 2 つのインスタンスを使用して、2 つのドロップダウン メニュー ComboBox ウィジェットを作成しています。それらをdeviceおよびcommandと呼びます。デバイスComboBoxで選択された値によって、コマンドComboBox で使用できる値が異なります。コマンドの選択が行われると、デバイスとコマンドの選択の組み合わせを使用して、より多くの作業が行われます (他の可能なパラメーターの表示など)。

通常、次のようなことが起こるはずです。

  1. デバイスウィジェットのモデルの入力と設定
  2. Connectデバイスハンドラ (「changed」イベント用)
  3. Connectコマンドハンドラ (「changed」イベント用)
  4. デバイスウィジェットを表示
  5. コマンドウィジェットを表示
  6. 選択を待ちます
  7. プロセスデバイスの選択、コマンドウィジェットのモデルのクリア/入力
  8. プロセスコマンドの選択
  9. 6へ

ここで、#8 の途中で、ユーザーが非常に高速に戻って別のデバイスを選択し、その 2 番目のデバイス選択イベントが処理される前に、別のコマンドを選択します(最初のデバイス選択から入力されます)。2 番目のコマンド選択イベントは、2 番目のデバイス選択イベントが処理された後に有効でなくなる可能性があるコンテキストで受信されます。

デバイス選択処理で次のようなことを行うのがベスト プラクティスです。

  1. コマンドウィジェットを非表示にする
  2. イベント キューをクリアします (保留中のすべてのイベントで gtk.gdk.event_get() を呼び出し、進行するにつれて解放します)
  3. コマンドウィジェットをクリア
  4. [再]コマンドウィジェットのモデルを作成する
  5. コマンドウィジェットを表示

または、別のよりエレガントな方法はありますか? つまり、強制的に発生させることができる自動イベントパージはありませんよね?

4

1 に答える 1

1

存在しない問題を解決しようとしていると思います。

最後の入力イベントをまだ処理している間に、次の入力イベントがすでに待機している可能性があることは理論的には正しいです。結局のところ、これらのイベントは、イベントの処理を待たない X プロセスから発生します。ただし、ウィジェットの状態は独自のメイン ループで順次更新されます。つまり、次の入力イベントは、ウィジェットの状態を変更した後に発生したかのように解釈されます。

つまり、コマンド 1 のオプションが表示されている間にユーザーがデバイス ウィジェットの上部のどこかをクリックした場合、コマンド 2 への変更を処理している間に、最終的にユーザーがクリックしたかのようにループによって解釈されます。コマンド 2 に対応する最上位のオプション。

ユーザーが処理できるよりも速くクリックできる場合、入力が意図したものとは異なるように解釈される可能性があることを認識するのは、ユーザーの責任です。処理がアプリケーションをブロックしないと仮定すると、これは合理的です。

もしそうなら、ベストプラクティスは、別のスレッドで再設定している間、他のウィジェットを無反応にすることだと思います。イベントのジャグリング/パージが必要な理由がわかりません。

補足として、ウィジェットを「再作成」していると言っているのでGtkTreeModel、コマンドにいくつかの s を使用して使用することを検討しましたgtk_tree_view_set_modelか?

于 2012-10-25T07:56:21.043 に答える