Question

I’m using two instances of gtk.TreeStore (in pyGTK 2.10) to create two drop-down menu ComboBox widgets; call them device and command. The value selected in the device ComboBox will vary the values available in the command ComboBox. When a command selection is made, the combination of device and command selections are used to do more work (showing other possible parameters, etc.)

Something like this should normally happen:

1. Populate and set model of device widget
2. Connect device handler (for “changed” event)
3. Connect command handler (for “changed” event)
4. Show device widget
5. Show command widget
6. Wait for selection
7. Process device selection, clearing/populating the model of the command widget
8. Process command selection
9. Go to 6

Now, say in the middle of #8, the user is really fast and goes back to select another device and, before that second device-selection event can get handled, they select another command (populated from the initial device selection). The second command-selection event is coming in with context that may no longer be valid after the second device-selection event is processed.

Is the best practice to do something like the following in device-selection processing:

1. Hide command widget
2. Clear event queue (by calling gtk.gdk.event_get() on all pending events, freeing as we go)
3. Clear command widget
4. [Re-]populate model of command widget
5. Show command widget

Or is there another more elegant way? I mean, there’s not some automatic event purging that can be forced to happen, right?

Answer 1

I think you’re trying to solve a non-existent issue.

You’re right that it’s theoretically possible for the next input event to be already waiting while you’re still processing the last one. After all, those events come from the X process, which doesn’t wait for you to handle the event. However, the state of your widgets is updated sequentially in your own main loop. That means that the next input event will be interpreted as if it happened after you changed the state of your widgets.

That means that if the user clicked somewhere in the top of your device widget while it shows the options for command 1, but while you’re processing the change to command 2, it will eventually be interpreted by your loop as if the user clicked the topmost option corresponding to command 2.

If the user can click faster than you can process, it’s her responsibility to know that her input may be interpreted different from what she intended. That is reasonable assuming that your processing doesn’t block the application.

If it does, then I guess best practice would be to make the other widget insensitive while you repopulate it in another thread. I don’t see why that would need any juggling/purging of events.

As a side note: since you say you’re ‘repopulating’ the widget: have you considered just having several GtkTreeModels for the commands and using gtk_tree_view_set_model?