On Mon, Feb 7, 2011 at 1:28 PM, DR0ID <dr...@bluewin.ch> 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
>
>
