Re: [SPAM: 3.100] Re: [pygame] GSoC

[Greg Ewing <greg.ewing@xxxxxxxxxxxxxxxx>]

David Burton wrote:

> 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,

Yes, this is exactly how modal dialogs are implemented in Albow,
by recursively calling the 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!

If the intent is to pause the game while the user is adjusting the
options, then this isn't a problem, because you don't want to resume
the game until the user backs out of the whole dialog.

If you want the game to be running while the options are adjusted
"live", so to speak, then I would say you don't want a modal dialog
at all. You want to put up the options window as a non-modal
widget and then return to the main event loop. The game will then
keep running as usual, and callbacks from the sliders, etc. will be
no further down from the main loop than the button callback that
started it all off.

The important thing is to break down a non-modal interaction into
a series of steps, each of which is triggered by one user action
and doesn't need to wait for any further user actions. Once you've
done that, there's no reason not to carry out each step directly
in the callback for the triggering action.

--
Greg