RE: [AD] new window hooks patch

["Vincent Penquerc'h" <vincent@xxxxxxxxxx>]

> The program can also ignore the ESC keypress, but when the user tries to
> close the window, nothing will happen (unless you hooked the event).
> The choice of simulating an ESC keypress is more a comfort than anything
> else: normally ESC has special behaviours, like terminating a program or
> bringing up a menu... So it seems like the best default action to
> simulate it
> when the user clicks on the window close button, as this fits
> perfectly in
> the way Allegro test programs/examples currently works: almost
> all them end
> when ESC is pressed, so with this patch applied when the user closes the
> window, the program will actually quit.
> If you think simulating a keypress when the user closes the
> window is bad, we
> could make that selectable: what about modifying set_window_close_hook to
> something like

well, it's just my opinion, but i find this to be very ugly (sorry) and
very specific. examples are just that, examples, and their goal is to
show off a particular feature, so they don't care about being good at
anything else: the faster to code the better. A real program is (well,
should be) something more elaborate, and often is. Each program has its
own behavior, and I think tying escape (or any other key for that matter)
to this event is a bad thing. I agree that it may be convenient for the
sake of tradition, but it's a bad thing IMHO.

And if you provide such a routine:

> set_window_close_hook(int keypress, void (*proc)())

why do you need this keypress ? Provide:

set_window_close_hook(void (*proc)())

The user would have something like:

void window_close_hook()
{
  exit(1); // convenience code of course :)
}

void init()
{
  // other code
  set_window_close_hook(&window_close_hook);
}

and then we're good to go, no ?
if the user wants an escape keypress, it's possible to put this in
the body for window_close_hook ...

I have the odd feeling that I'm missing something important here :)

--
Lyrian