GNOME Bugzilla – Bug 616674
Vfuncs require me to implement methods that shouldn't be required
Last modified: 2010-04-28 17:47:31 UTC
With the latest from git adding an override for GtkBuilder class Builder(Gtk.Builder): def connect_signals(self, obj_or_map): . . . causes this error when running a pygi app Traceback (most recent call last):
+ Trace 221533
import dfeet.DFeetApp as DFeetApp
from gi.repository import Gtk
overrides_modules = __import__('gi.overrides', fromlist=[namespace])
class Builder(Gtk.Builder):
cls._setup_vfuncs()
vfunc_info.get_name()))
I've never had to override that method before and am not sure how I would. Another point is that vfuncs in pygtk use the on_ prefix not the do_ prefix. This causes issues with my implementation of GenericTreeModel which requires a number of vfuncs to be implemented.
Overrides classes shouldn't be proper subclasses as in they shouldn't register a GType.
(In reply to comment #0) > I've never had to override that method before and am not sure how I would. True, this restriction should only apply when implementing an interface, not when inheriting from a class with vfuncs. > Another point is that vfuncs in pygtk use the on_ prefix not the do_ prefix. Hmm, what I guess happens is that vfuncs that are event handlers use the on_ prefix, and the rest of vfuncs use do_. I'm not sure how we could know that a vfunc is one or the other without adding one more annotation.
Created attachment 159601 [details] [review] Dont force to implement all vfuncs of its bases, only when the base is an interface
We still have an issue with the GenericTreeModel in the override file. It still gets registered and then fails because we are not implementing the vfuncs. Note that it doesn't get the override decorator to fix a previous bug.
Created attachment 159634 [details] [review] [PATCH] add the GenericTreeModel override and the GtkBuilder override gi/overrides/Gtk.py | 111 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 110 insertions(+), 1 deletions(-)
Created attachment 159635 [details] Test for gtkbuilder This doesn't currently work after the vfunc changes were added
Created attachment 159636 [details] ui test file
I don't know if we want a separate bug but it seems related since the test I attached used to work until the vfunc code was added. It looks like we are getting back invalid type data when loading widgets from a ui file. Attached is the patch for the Gtk.py override file and a python test along with the ui file. I am getting this error when running the test with all patches in this bug applied: /home/johnp/devel/gnome-shell/install/lib64/python2.6/site-packages/gtk-2.0/gi/types.py:109: Warning: cannot unreference class of invalid (unclassed) type `GtkTreeModel' vfunc) TypeError: 'NoneType' object is not callable /home/johnp/devel/gnome-shell/install/lib64/python2.6/site-packages/gtk-2.0/gi/types.py:40: Warning: cannot retrieve class for invalid (unclassed) type `(null)' return info.invoke(*args) ** Gtk:ERROR:gtkbuilder.c:259:gtk_builder_get_parameters: assertion failed: (oclass != NULL) Aborted (core dumped) It seems we are trashing the stack somewhere because the types.py warning sometimes comes back with a type name instead of (null). Another interesting point is the TypeError:'NoneType' comes back when we execute gtk_builder_get_type_from_name in gtk/gtkbuilder.c. On the line which reads return GTK_BUILDER_GET_CLASS (builder)->get_type_from_name (builder, type_name); we should be executing gtk_builder_real_get_type_from_name which the vfunc is set to. It never gets there. This leads me to believe we are failing at GTK_BUILDER_GET_CLASS (builder). I have written a C test that does the same thing as the python test and it works without an issue. Also if I take out the builder override the widgets do show up but then we lose the connect_signals override so no signals are connected.
Ah, ha. Tracked it down. GTK_BUILDER_GET_CLASS (builder) works fine. I edited the Gtk code to make it easier to debug. Apparently we are still overriding vfuncs on overridden classes even if there is an internal default. Breakpoint 1, IA__gtk_builder_get_type_from_name (builder=0x6ec2d0, type_name= 0x7e3d10 "GtkWindow") at gtkbuilder.c:1598 with override: (gdb) p bc->get_type_from_name (GType (*)(GtkBuilder *, const char *)) 0x7ffff7fef010 without override: (gdb) p bc->get_type_from_name $1 = (GType (*)(GtkBuilder *, const char *)) 0x7fffed8e9f02 <gtk_builder_real_get_type_from_name>
Created attachment 159644 [details] [review] [PATCH] if the method is not overridden by the user, don't set vfunc to None * in the case where we have a class which has a vfunc which may already be implemented on the C level, we do not want to replace this with a None object. In fact in the case where vfunc (the user supplied vfunc) evaluates to None, we never want to set the class vfunc to None because None is not a callable object and will throw an error when the vfunc is invoked --- gi/types.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Review of attachment 159644 [details] [review]: I'm very confused by this, no matter how many times I read the code, I don't see how this patch could have any effect. In any case, could you add a test case?
Review of attachment 159644 [details] [review]: Ah, gotcha, this patch applies on top of my previous patch, I see where's the issue now. Will add a test case myself.
Created attachment 159676 [details] [review] Dont force subclasses to implement all virtual methods of their bases
Review of attachment 159676 [details] [review]: Looks good. Only suggestion would be to add a test object that does override the default to make sure it can still do that (though that test may already be somewhere else).
(In reply to comment #14) > Review of attachment 159676 [details] [review]: > > Looks good. Only suggestion would be to add a test object that does override > the default to make sure it can still do that (though that test may already be > somewhere else). Yup, that is tested some lines above.
Comment on attachment 159676 [details] [review] Dont force subclasses to implement all virtual methods of their bases Attachment 159676 [details] pushed as 1d9c6b6 - Dont force subclasses to implement all virtual methods of their bases