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

[Greg Ewing <greg.ewing@xxxxxxxxxxxxxxxx>]

David Burton wrote:

> Some dialogs have a "backing out" operation (the "close" button, or the 
> "ok" button, or whatever).  But many don't.

If it's a *modal* dialog, it *has* to have some way of backing
out. Conversely, if it doesn't, it has to be non-modal.

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

No, it's not, because in the non-modal case, the only thing the
button callback does is make the window with the sliders in it
appear, then it *returns*. By the time the user clicks on the
slider, the button callback is ancient history just the same.

To implement the interaction non-modally using events, the
handler for the button-click event has to obey the same
restriction -- i.e. it must simply make the window appear, and
do nothing further. If it tries to wait for any more input
itself, then you still have a nested event loop, and nothing
has really changed.

Non-modal using callbacks:

  Main event loop receives mouse down in button
    Button callback makes option adjustment window visible
  Main event loop receives mouse down in slider
    Slider callback changes game state

Non-modal using events:

  Main event loop receives mouse down in button
    Button callback posts button-click event
  Main event loop receives button-click event
    Button-click handler makes option adjustment window visible
  Main event loop receives mouse down in slider
    Slider callback posts slider-click event
  Main event loop receives slider-click event
    Slider-click handler changes game state

There's no more nesting one way than the other, and the event
version is more complicated.

Modal using callbacks:

  Main event loop receives mouse down in button
    Button callback makes option adjustment window visible
      Nested event loop receives mouse-down in slider
        Slider callback changes game state

Non-modal using events:

  Main event loop receives mouse down in button
    Button callback posts button-click event
  Main event loop receives button-click event
    Button-click handler makes option adjustment window visible
      Nested event loop receives mouse-down in slider
        Slider callback posts slider-click event
      Nested event loop receives slider-click event
        Slider-click handler changes game state

Again, they're both equally nested, and the event
version is more complicated.

So I maintain that the key difference is not callbacks vs.
events, but modal vs. non-modal. If you have a nested event
handling structure, switching from callbacks to events *on
its own* doesn't change the fact that it's nested.

To get rid of the nesting, you have to restructure things
so that the interaction is non-modal -- and you can do that
just as effectively and more simply using direct callbacks,
without any need to involve events.

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

The structures I've described do match the way the user thinks.
If the interaction is modal, the user thinks of it as a nested
activity, and this is reflected in the nested structure of the
code. If it's non-modal, the user doesn't think of it as nested,
and the code structure is flat.

--
Greg