On Mon, Feb 7, 2011 at 1:28 PM, DR0ID
<dr0id@xxxxxxxxxx> wrote:
Hi
" from deep within the GUI code itself" <-- how does that get
called? from the event loop?
In a typical pygame app, the event loop is simply the outermost level of the application. So if the GUI toolkit uses callbacks to communicate its results to the application code, then when one of those callbacks into the application gets called, it's nested something like this:
main / event-loop sees mouse click, calls
-> GUI toolkit event notification code, calls
-> button widget event notification method, calls
-> application callback for the button click
Now we're back in application code. It gets the (for example) button click callback, which tells it that the user wants to (for example) adjust his game settings. So the application code calls
-> an application function to adjust game settings, which calls
-> GUI toolkit to put up a form with check-boxes and sliders,
...which which had better be modal, running its own event loop, because you're now a loooog way from the application's main event loop!...
-> which sees a slider adjustment, and calls
-> application callback for the slider adjustment
...and now we're back in the application, and we know what the user wants of us, but we're a looog way from being able to resume the game! We're simultaneously inside two callback functions, one for a button and one for a slider, as well as an unknown number of functions and methods inside the GUI toolkit, and two different event loops! The application can't just make the requested setting change and resume running the game. It has to return from the slider's callback, get control back from the GUI toolkit in the button callback, return from that, and finally get control back in the main event loop, all before the game can resume.
and pushing the events on the pygame event loop could be dangerous
because it is possible that there are already other events on the
queue that will change the state of the application (or gui
elements) so that at the time when your event gets processed it
brakes (because the application isn't in the state anymore it was
when the event was posted).
It's not a problem. Remember what these events represent: they are notifications of things that the user did, like "user clicked a button," or "user entered text," etc.. They are very infrequent compared to things like mousemotion events.
What's more, like all events, they don't stay in the event queue for long at all. If the user clicked a button while moving his mouse across it, a few mousemotion events might be in the queue, either before or after the button-click event, but it really doesn't matter. The response to the button-click is going to look instantaneous to the user, anyhow. There's no reason that the application should brake or exhibit some strange bug just because it processed a few mouse movements before it noticed that a button had been clicked.
If the application exhibits strange bugs due to other events being processed before the GUI-generated events, that means it is so delicate & timing-dependent that it matters if the user clicks a couple of milliseconds too early or late.
This is a very subtle bug and difficult
to catch. Not sure how to avoid that behavior (maybe posting the gui
internal events at the front of the event queue?).
It wouldn't matter. Posting at the front might make the application notice the button click (or menu choice, or check-box change, or whatever) a couple of milliseconds earlier. It matters no more or less than whether the user clicks a couple of milliseconds earlier or later.
Therefore I think
callbacks are easier to work with. But I'm not entirely sure how to
handle reentrant calls, if there are any (is the recursion a problem
at all?). Normally only one user interaction (event) is processed at
the time. So i wonder:
"When the second user interaction gets its result, and makes its callback
to the application"
How?
Just my opinion.
~DR0ID