GNOME Bugzilla – Bug 543056
gobject.type_register() no longer needed
Last modified: 2011-01-18 12:12:14 UTC
Please describe the problem: pygtk 2.12.0 http://live.gnome.org/PyGTK/WhatsNew28 says "Now GObject's are better integrated into python. For one thing, it is no longer needed to call gobject.type_register(MyClass) on subclasses, ever ..." Edit examples/gtk/widget.py to remove the unnecessary call to gobject.type_register(PyGtkWidget) and run the example. It reports the error: Traceback (most recent call last):
+ Trace 202866
sys.exit(main(sys.argv))
w = PyGtkWidget(TEXT)
gtk.Widget.__init__(self)
- it looks like pygtk 2.12 has regressed to the behaviour before version 2.8 Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Do you have PyGTK 2.8 around? In 'gobject/__init__.py' there are these lines: if not ('__gproperties__' in namespace or '__gsignals__' in namespace or '__gtype_name__' in namespace): return Which means that types with neither of those three attributes don't get autoregistered. Was it different in 2.8? Or maybe all standard classes just had some of the attributes set, so that subclasses got it automatically? (Difficult to trace down by sources, since type autoregistering has been moved from C part to Python part.)
I dont have pygtk 2.8 installed (just Fedora 8 with pygtk 2.12 and Fedora 7 with pygtk 2.10). pygtk 2.10.4 with pygobject 2.12.3 demonstrated the same problem. In 'gobject/__init__.py': class GObjectMeta(type): "Metaclass for automatically registering GObject classes" def __init__(cls, name, bases, dict_): type.__init__(cls, name, bases, dict_) cls._install_properties() cls._type_register(cls.__dict__) # ... def _type_register(cls, namespace): ## don't register the class if already registered if '__gtype__' in namespace: return if not ('__gproperties__' in namespace or '__gsignals__' in namespace or '__gtype_name__' in namespace): return type_register(cls, namespace.get('__gtype_name__')) I can understand the check for '__gtype__' - don't register the class if it is already registered. But why the '__gproperties__', '__gsignals__', '__gtype_name__' clause - what does it achieve? type_register() already checks that the class is a GObject subclass, so why are further checks necessary? Removing the '__gproperties__', '__gsignals__', '__gtype_name__' clause fixes the problem.
See bug 311226 for why it is needed (it seems, at least). Feel free to find a way to remove '__gproperties__' etc. clause but avoid the problem outlined in that bug report.
That's easy - just comment out the if not ('__gproperties__' in namespace or '__gsignals__' in namespace or '__gtype_name__' in namespace): return clause and run the foodialog.py attached test case and the problem reported in bug 311226 is still avoided. This is because the __gproperties__ clause does *not* fix bug 311226, the bug was fixed by a patch against GTK+. The __gproperties__ clause was a side issue which arose from the bug's discussion. It's intention was to "Do not automatically register a type if not needed." However, this bug report demonstrates that the clause avoids registering a type when it *is* needed - so its not working as originally intended.
Well, it _seems_ the problem is gone because gtk.MessageDialog constructor is now new-style (with GTK+ 2.10 and up). Also, the problem seems to be gone for everything that uses relatively new function pygobject_register_wrapper() (new-style constructors do use that). However, while it seems that all class in PyGTK are now safe, I cannot say for sure that doing as you suggest will not break inheriting non-PyGTK classes. I leave this bug to someone who better understands these low level mechanics (Gustavo?).
Created attachment 178537 [details] [review] Always register a new GType when a GObject class is subclassed This patch makes the GType <-> python mapping much more predictible, and fixes the bug caused by overriding methods without specifying a __gtype_name__ member in the subclass, and makes type_register useless for real :-) It is still possible to provide an explicit __gtype_name__ member in the subclass as it allows having a predictible GType name, which is handy for some of our tests. There is also an explicit special case for overrides because we obviously do not want to register new GTypes for those ones as it would clearly defeat the purpose of overrides.
Created attachment 178540 [details] [review] Always register a new GType when a GObject class is subclassed I forgot to remove a debug line in the previous patch...
Attachment 178540 [details] pushed as 84d6142 - Always register a new GType when a GObject class is subclassed