On Mon, Feb 7, 2011 at 3:52 PM, Greg Ewing
<greg.ewing@xxxxxxxxxxxxxxxx> wrote:
David Burton wrote:
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,
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 looong 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.
Some dialogs have a "backing out" operation (the "close" button, or the "ok" button, or whatever). But many don't. There's no backing out of a singleton button. It just clicks.
In the above scenario, as far as the user is concerned, the button click has already happened, and it's ancient history by the time the slider adjustment happens.
If the GUI is structured to use events to report its results, the button click is ancient history to the GUI, too.
But if the GUI is structured to use callbacks, then the button click code is still running, seconds or minutes later, when the user is adjusting the slider. It's still down in the bowels of the button's event notification method, calling a callback which hasn't yet returned.
That represents a mismatch between how the user uses the UI and how the code implements it, which is a dead giveaway of a structural problem.
Dave