使用gtk.TreeStore和gtk.ComboBox时的并发控制

时间:2012-10-24 19:16:11

标签: events concurrency gtk pygtk

我正在使用两个gtk.TreeStore实例(在pyGTK 2.10中)来创建两个下拉菜单ComboBox小部件;称他们为设备命令。在设备 ComboBox中选择的值将改变命令 ComboBox中可用的值。当选择命令时, device command 选项的组合用于执行更多工作(显示其他可能的参数等)

通常会发生这样的事情:

  1. 填充并设置设备小部件的模型
  2. 连接设备处理程序(用于“已更改”事件)
  3. 连接命令处理程序(用于“已更改”事件)
  4. 显示设备小部件
  5. 显示命令小部件
  6. 等待选择
  7. 处理设备选择,清除/填充命令小部件的模型
  8. 处理命令选择
  9. 转到6
  10. 现在,在#8中间说,用户非常快,然后返回选择另一个设备,然后在第二个设备 - 选择事件之前处理后,他们选择另一个命令(从最初的设备选择中填充)。第二个命令 -selection事件将进入上下文,在处理完第二个设备 -selection事件后,该上下文可能不再有效。

    最佳做法是在设备 - 选择处理中执行以下操作:

    1. 隐藏命令小部件
    2. 清除事件队列(通过在所有待处理事件上调用gtk.gdk.event_get(),随时释放)
    3. 清除命令小部件
    4. [重新]填充命令小部件的模型
    5. 显示命令小部件
    6. 还是有另一种更优雅的方式吗?我的意思是,没有一些自动事件清除可以强制发生,对吧?

1 个答案:

答案 0 :(得分:1)

我认为你正试图解决一个不存在的问题。

你说得对,理论上下一个输入事件在你还在处理最后一个事件时已经在等待了。毕竟,这些事件来自X进程,它不等待你处理事件。但是,窗口小部件的状态会在您自己的主循环中按顺序更新。这意味着下一个输入事件将被解释为在您更改窗口小部件的状态后发​​生的事件。

这意味着如果用户在显示命令1的选项时单击设备窗口小部件顶部的某个位置,但是当您处理对命令2的更改时,它最终会被您的循环解释,就像用户单击了与命令2对应的最顶层选项。

如果用户点击的速度超出了您的处理速度,那么她有责任知道她的输入可能与她的意图有所不同。假设您的处理不会阻止应用程序,这是合理的。

如果确实如此,那么我想最佳做法是在另一个线程中重新填充其他窗口小部件时使其不敏感。我不明白为什么需要任何杂耍/清除事件。

作为旁注:因为你说你正在“重新填充”小部件:你是否考虑过为命令提供多个GtkTreeModel并使用gtk_tree_view_set_model