David Burton wrote:
(That's because, if you are an experienced programmer, you have learned [probably the hard way] that you really don't want to start anything complicated in response to a click if you're deep in the bowels of the GUI code [which has called your callback function], since the complicated thing you start might want to /use/ that same GUI code, and get button clicks and menu choices of its own, leading to ever deeper recursion in the [hopefully reentrant!] GUI code, and mind-bending complexity and bugs.)
I can't really see how using events helps with that, because if there's a complicated thing to be done, it needs to be done somehow or other, and either way it's being done by a piece of code being called from the event loop, which will hold up the GUI until it's finished. I don't mean to say that it's *wrong* to use events this way -- if you find the technique helpful, then that's fine. It's just that the problem you're describing doesn't seem to arise for me, and I don't think it would simplify anything in the way I write my game code.
*However, I have noticed that pygame events are somewhat weird. They are objects, but they don't always behave like proper Python objects. There's no __dict__ attribute, and dir() doesn't work,
According to the docs, they have a dict() method instead. -- Greg