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

我在PyGTK2.10中使用了gtk.TreeStore的两个实例来创建两个下拉菜单组合框小部件；称之为设备和命令。在设备组合框中选择的值将改变命令组合框中可用的值。当进行命令选择时，设备和命令选择的组合用于进行更多工作，显示其他可能的参数等

这样的事情通常会发生：

填充并设置设备小部件的模型 连接已更改事件的设备处理程序 已更改事件的Connect命令处理程序 显示设备小部件 显示命令小部件 等待选择 处理设备选择，清除/填充命令小部件的模型 进程命令选择 去6号

现在，假设在8中，用户真的很快，然后回去选择另一个设备，在第二个设备选择事件得到处理之前，他们选择从初始设备选择中填充的另一个命令。处理第二个设备选择事件后，第二个命令选择事件中的上下文可能不再有效

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

隐藏命令小部件 通过调用gtk.gdk.event_获取所有挂起的事件来清除事件队列，并在执行过程中释放 清除命令小部件 [Re-]填充命令小部件的模型 显示命令小部件

---

还是有其他更优雅的方式？我的意思是，没有什么自动事件清除可以强制发生，对吗？

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

您是对的，理论上，下一个输入事件可能已经在等待，而您仍在处理最后一个输入事件。毕竟，这些事件来自X进程，它不等待您处理事件。但是，小部件的状态在您自己的主循环中按顺序更新。这意味着下一个输入事件将被解释为发生在您更改小部件状态之后

这意味着，如果用户在显示命令1的选项时单击了设备小部件顶部的某个位置，但在您处理对命令2的更改时，您的循环最终会将其解释为用户单击了与命令2对应的最上面的选项

如果用户的点击速度比您的处理速度快，那么她有责任知道她的输入可能会被解释为与她预期的不同。假设您的处理不会阻止应用程序，这是合理的

如果是这样的话，我想最好的做法是在另一个线程中重新填充另一个小部件时使其不敏感。我不明白为什么这需要任何杂耍/清除事件

---

作为旁注：既然你说你正在“重新填充”小部件：你有没有考虑过只为命令使用几个GtkTreeModels，并使用gtk_tree_view_set_model？

即使你让这个应用程序成为多线程的，我也不明白为什么，GUI的事件处理总是从一个主线程开始，因此，永远不会有任何并发问题。即使我使其他小部件不敏感，我也可能会重新填充模型。。。哦，嗯。这个事件只是告诉我，有些事情发生了变化，我必须去说，相对于现在存在的模型，世界的状态是什么，正如我认为@Ancurio所指出的，当我着手处理第二个事件时，世界一定是一个自洽的世界。