GNOME Bugzilla – Bug 311226
Metaclass registration causes breakage with old constructors
Last modified: 2006-01-09 14:13:40 UTC
I haven't looked in detail at the problem yet, but it seems like the fix for bug #161177 which introduces a new API for constructors breaks existing code. E.g. if you run the attached test case, you get: [markmc@blaa foo]$ python foodialog.py ** (foodialog.py:9081): WARNING **: Constructor wrapper for GtkMessageDialog needs to be updated to the new API Traceback (most recent call last):
+ Trace 61933
FooDialog (None).run ()
gtk.MessageDialog.__init__ (self, parent_window, 0, gtk.MESSAGE_WARNING, gtk.BUTTONS_OK_CANCEL)
(Marking as a blocker since its API incompat, basically)
Created attachment 49554 [details] [review] foodialog.py
I've put this comment in the constructor for GtkMessageDialog: /* Note: with current API (gtk 2.4), it is impossible to * construct a GtkMessageDialog through g_object_new(), because * there is no 'message' property and the label field is * private */ I think it still applies. The main problem is that there is no 'message' property, nor there is gtk_message_dialog_set_message. You have to use the factory function.. In any case, since the constructor doesn't use g_object_new, I added that check/exception to prevent more subtle bugs. So, you should use __gobject_init__ or GObject.__init__. This is certainly not a regression from 2.6, and is unrelated to bug 161177. Yes, there is a bug, but we can't fix without a new gtk+ API. Unfortunately I was too lazy to propose such an API in time... :P But since you opened the bug, let's retitle it and leave it open.
OK, after so discussion I realize this problem is also related to metaclass automatic registration. While before you could use an old-style constructor if you didn't register the subclass, now subclasses are implicitly registered, which makes the GType for the subclass change and triggers that exception in the gtk.MessageDialog constructor. And indeed this is a regression; miraculously, the code did work before! A possible solution would be to, in the metaclass, check if neither __gproperties__, __gsignals__, nor __gtype_name__ are defined, in which case we skip registration. Anyone against this?
One problem - you'd need to allow people to explicitly call gobject.type_register() on classes which don't have __gproperties__, __gsignals__ or __gtype_name__ - i.e. you shouldn't get a deprecation warning in that case.
Yes, this is already possible. You don't get a deprecation warning now (2.7.x) when calling gobject.type_register() on a subclass that wasn't registered.
I bug 311254 against Gtk+ which should solve the ::message problem, but we have to wait until 2.10. So there are two separate bug reports here, 1) Make it possible to subclass GtkMessageDialog's 2) Do not try to register a type twice.
Actually 2) should be: "Do not automatically register a type if not needed." def registration_is_needed(cls): return (hasattr(cls, "__gtype_name__") or hasattr(cls, "__gsignals__") or hasattr(cls, "__gproperties__"))
Problem 2) got fixed in CVS the way I described.
Fixed also gobject.type_register deprecation warning; Now only a warning when trying to register a type that is already registered. Opened the MessageDialog problem as separate bug 312056.