Re: [AD] set_window_close_button_callback_hook_button()

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On Fri, Nov 29, 2002 at 05:17:38AM +0000, Ben Davis wrote:
> [No need to cc to me when replying.]

Hmm... don't know about other developers, but when replying, I usually hit
reply all (or group reply) and then delete everything but conductors@xxxxxxxxxx
Sometimes I forget the last step, though. Nothing personal :)

> > Only applies to stable branches. We can't guarantee API compatibility
> > during development.
> 
> Then that should be noted in api.txt ;)

IMHO, this should be implicidly obvious for WIP releases. WIP release 1 might
add a feature, while WIP release 1+1 might change it again. Then again, adding
a note to the docs won't hurt.

> > The functionality has changed: set_close_button_callback() has superseded
> > the two former functions. In particular, set_close_button_callback(NULL)
> > must physically disable the close button.
> 
> So, whenever the warning message / forced close was would have appeared, the 
> button gets disabled instead. I fail to see how this change would break any 
> programs (in particular, if they were relying on the warning message, then 
> they were broken already).

The claim wasn't that programs were broken, but that the functionality was
changed. IMHO, programs relying on the message box weren't exactly broken.
They were relying on Allegro to close the program correctly.

> > > set_window_close_button() will enable or disable the close button, as
> > > before. It will default to enabled. HOWEVER, the button isn't _actually_
> > > enabled unless a callback has been specified; until then, it'll appear
> > > greyed out, or be inoperative, depending on the window manager or
> > > whatever.
> > >
> > > set_window_close_hook() will set a callback function. The close button
> > > will light up (or become operative), provided it is "enabled" as defined
> > > for the last function. If NULL is specified here, the close button will
> > > appear greyed out or be inoperative, even though it's "enabled" as
> > > defined for the last function.
> >
> > These functions are not orthogonal. Only one function for one
> > functionality.
> 
> Which is why we have draw_sprite() and masked_blit().

Ehm... draw_sprite() and masked_blit() perform a similar task. What does this
have to to with one function for enableing a close button and one for setting
a handler? These are not similar tasks.
What's the point of enabeling a close button that's going to be disabled until
you call another function anyway? Why would you have to explicidly enable it
if you register a callback function? Why would you do that if you do not
intend to use the thing?
In short, registering a callback function logically implies the activation of
the close button, and set_window_close_button() is unneeded.

> > We do break the API: the behaviour of a function has changed. Keeping the
> > same name would be worse.
> 
> That's only a rule of thumb, and it doesn't apply here. I challenge you to 
> think of a single scenario where a program would be broken by such a change.

While you may be right, IMO it's a good rule of thumb.

Evert