Created attachment 174977 [details]
test program

I don't see any response vfuncs, only a signal.  In which case you need to do a dialog.connect('response', self.do_response, None)

mmm... weird, note that the same code used to work in pygtk

Beside GtkDialog has response vfunc:

...
struct _GtkDialogClass
{
  GtkWindowClass parent_class;

  void (* response) (GtkDialog *dialog, gint response_id);
...

It turns out that signal overriding is totally missing in pygobject.
I am changing the summary.

The following patch implements it, but it does not actually work since it seems that get_class_closure never returns anything from the g-i side of things :(

Created attachment 175269 [details] [review]
patch

I hope that soon vfuncs associated to a signal will appear in the .gir like the others, so this won't be needed.

I think that even if signal vfunc are reported in the gir, there are still problems to be fixed (and maybe in part addressed by this patch):

 - get_class_closure should either be fixed in gi, wrapped and used in pygobject or dropped from g-i... at the moment it is very confusing to understand which is the proper way to obtain a signal vfunc
 - while conventionally signals have a vfunc in the class struct, that is not mandatory

(In reply to comment #8)
> I think that even if signal vfunc are reported in the gir, there are still
> problems to be fixed (and maybe in part addressed by this patch):
> 
>  - get_class_closure should either be fixed in gi, wrapped and used in
> pygobject or dropped from g-i... at the moment it is very confusing to
> understand which is the proper way to obtain a signal vfunc

Why do app authors need to obtain a signal's vfunc? If all vfuncs make to the .gir, app authors can choose to implement/override any of the available vfuncs, or listen to signals. The API author decides what should be available.

>  - while conventionally signals have a vfunc in the class struct, that is not
> mandatory

How could you override a signal? You override vfuncs and that's now possible as all vfuncs will be present in the .gir.

(In reply to comment #9)
> 
> How could you override a signal? You override vfuncs and that's now possible as
> all vfuncs will be present in the .gir.

I think the object has the infrastructure to override signal handlers without having access to the vfunc pointer in the class structure:

 g_signal_override_class_closure

I think it was added to be able to add signals without breaking ABI. I am not sure how common its use is.



That said, my point is very simple: g-i has the function g_signal_info_get_class_closure but it is currently broken. If the bindings do not need to use it, it should be removed, if the bindings need it then it should be fixed and pygobject should use it.

(In reply to comment #10)
> (In reply to comment #9)
> 
> That said, my point is very simple: g-i has the function
> g_signal_info_get_class_closure but it is currently broken. If the bindings do
> not need to use it, it should be removed, if the bindings need it then it
> should be fixed and pygobject should use it.

Ok, right now I cannot see any need for it. Should this ticket be closed or reworded somehow?

Comment on attachment 175269 [details] [review]
patch

In case we still want this, the patch will need a testcase.

The demo program works just fine now, i. e. you can just simply override the do_response() function now. So the primary issue here is fixed.

Bug 434924 deals with making it easier to define new signals, BTW.