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