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

[Casey Duncan <casey@xxxxxxxxxxx>]

On Feb 7, 2011, at 2:15 PM, David Burton wrote:

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

I'm not sure that I understand this argument. If a button click is going to last a very long time, then the application needs to inform the user of this (spinner, wait indicator, etc). This probably would only happen if the application was making some blocking i/o call, or it's doing some long running cpu-intensive operation.

Let's assume for a second that events solve this problem. In a typical game-type application how many potentially long-running operations would there be relative to all GUI invoked operations in the app? I would argue that the common case would be very few, if any. So, if that's true, how hard would it be to have the callback for a few operations fire an event? My point being that callbacks and events are not mutually exclusive.

It doesn't make sense in general to complicate the common case to accommodate the special case. Let the special case be a little harder, and the common case be easier. Don't make me decouple everything when I don't want to, but make it possible if I do.

The other problem with this argument is the assumption that events solve problems like blocking i/o and long running cpu-intensive things on their own. They don't. You'll need to call in other tools like: async i/o, multiprocessing, etc. (I'm going to steer clear of threads <wink>) And once you do that, you can just use a callback again because it can return immediately once it kicks off the parallel process, which fires another callback when it's done. You can also use events to signal these things, of course, but both are viable.

Another thing I hate about event handlers is that they encourage coding insanely long if/elif structures that seem just fine in the beginning, but grow into monstrosities over time. They too easily become "god functions". There are ways around that, but they require more forethought. Callbacks, on the other hand tend to encourage nice, short, single purpose functions, which I find scale much better.

-Casey