[gtkada] GtkAda signal handlers interface proposal

[Emmanuel Briot]

> That reason and because it requires instantiation from Gtk.Handlers anyway. Automatic handler disconnection is rarely an issue.

For the instantiation => you can either use the already existing instances from gtkada-handlers.ads,
or use the generated On_* procedure. Then there is no need for any extra instance, which indeed makes
the code easier to read.

> The abstract procedure/function could be named "Handle" or "Execute", but Something_<signal name> has that big advantage that the handler object may handle many different signals by implementing multiple interfaces:

Agreed

> Actually I considered means to prevent this sort of misuse. E.g. by having the handler object as a plain parameter rather than access-to-object. This construct does not make sense in my view, because the purpose is to have some existing (visible elsewhere) object passed to the handler callback. If the handler object can be that sort anonymous, the existing callback procedures do the job nicely

Whether to pass an existing object or a new object is left to the user (the proposal does not force
either), so we need to handle that properly.

> The handler interfaces will then be
> 
>    type Clicked_Handler is interface and GObject_Interface;
> 
> This will allow calling Ref/Unref or even conversion to GObject_Record (risking Constraint_Error at run-time). The user will not be able to use an arbitrary type as a handler's base. Only descendants of GObject_Record will be eligible or else he will be forced to implement reference counting operations.

Right, that's forcing all handlers to be GObject compatible, which is not so attractive (there are
other pure-Ada ways to have refcounted types, for instance using controlled types).

Personally not a big fan of having all handlers be descendants of GObject (although admittedly this
is fully compatible with having the widget themselves be the handlers. But then when a dialog contains
multiple checkboxes, for instance, the handler indeed would have to be a big list of "if .. elsif" statements,
which I don't like because that's not quite "object-oriented" enough.

> The purpose is to have My_Widget_Record as a parameter. Handling automatic disconnection is not so interesting, however, having *_Handler a descendant of GObject_Interface will allow transparent disconnection handling if the handler gets prematurely destroyed.

Can you explain "handling automatic disconnection" is not so interesting ?
To me, it is important that handlers be disconnected when the object is destroyed, and then memory freed
appropriately.

>> I would have:
>> 
>>      type My_Widget_Record is new Gtk_Button_Record with ...
>> 
>>      type My_Click_Handler is new Clicked_Handler with null record;
>>      overriding procedure On_Click (...)
>> 
>>      Widget.Button1.On_Click (new My_Click_Handler)
>> 
> This is a very specific case, which better be:
>    type My_Widget_Record is new Gtk_Button_Record with private;
>        
>    type My_Click_Handler is new Clicked_Handler with null record;
>    overriding procedure On_Click (...)
> 
>    Handler : My_Click_Handler; -- Or placed in My_Widget_Record
> 
>    Widget.Button1.On_Click (My_Click_Handler);
> 
> Existing callback procedures do this better.

To me, existing callbacks do all the examples that have been discussed so far better. If all we want
is to pass a parent widget, this is already fully handled by the Slot argument, with no additional
instances needed, and are not worth the extra development or the increase in size of libgtkada.

The new proposal is only interesting to replace the User_Data packages from Gtk.Handlers, which in
my own experience are almost never needed.

Emmanuel