[gtkada] Signal handler

[Emmanuel Briot]

> Maybe the names Connect and Handle should rather include the event name.
> E.g. Connect_To_Clicked and Handle_Clicked. That would ease adding handler
> interfaces to the composite widgets.

I'd rather use names like On_Clicked, or something.

I understand all the advantages you described (and of course they are not new, 
that's one of the standard design patterns). I still find the user's code a bit 
heavy. There might be a middle ground somewhere.


>        type Delete_Main is
>            new Delete_Event_Handler with null record;
>        overriding function Handle_Delete_Event
>           (  Handler : in out Delete_Main;
>              Widget : not null access Gtk_Widget_Record'Class;
>              Event : Gdk_Event
>           ) return Boolean;

A function with "in out" parameter is for the next generation of Ada, not Ada12.

By the way, since we would be generating the code, we could indeed generate a 
"not null access" if the user passes a -gnat05 switch. Currently, we do not 
expect users to generate the sources on their machine, since that requires a 
python installation which might not always be available.

>
>     Window      : Gtk_Window;
>     On_Destroy : Destroy_Main;
>     On_Delete  : Delete_Main;
> begin
>     Gtk_New (Window);
>     Window.Connect_To_Destroy_Event (On_Destroy);
>     Window.Connect_To_Delete_Event (On_Delete);

This code is very dangerous. Nothing prevents users from connecting a local 
variable with the widget. What happens then when the gtk+ signal is emitted ?
Basically, you are forcing users to use global variables for your handlers, or 
perhaps you could change the interface to use pointers but then it is unclear 
when the pointers can be freed.

The approach taken (and now abandoned) by Java was to subclass:

   type My_Window is new Gtk_Window_Record with private;
   overriding procedure On_Delete_Event (Self : My_Window) return Boolean;

At least that solves the lifetime issue (the callback exists as long as the 
window). But this scheme isn't flexible enough to handle gtk+: with gtk+, you 
can connect a signal to a widget, but pass another Slot_Object that will be 
passed to the callback.

> BTW, did you consider possible impact of turning GObject_Record limited? It
> would make life much easier when developing user and composite widgets.

I don't think we have looked at this approach. Since we are mostly manipulating 
pointers in GtkAda, it might be a simple matter of adding "limited" in the 
declaration. Can you check whether it works ?