0

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

通常应该发生这样的事情：

  1. 填充和设置设备小部件的模型
  2. 连接设备处理程序（用于“更改”事件）
  3. 连接命令处理程序（用于“更改”事件）
  4. 显示设备小部件
  5. 显示命令小部件
  6. 等待选择
  7. 处理设备选择，清除/填充命令小部件的模型
  8. 工艺指令选择
  9. 前往 6

现在，假设在#8 的中间，用户真的很快并返回选择另一个设备，并且在处理第二个设备-selection 事件之前，他们选择了另一个命令（从初始设备选择中填充）。第二个命令选择事件与处理第二个设备选择事件后可能不再有效的上下文一起出现。

在设备选择处理中执行以下操作的最佳做​​法是：

  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 回答