GNOME Bugzilla – Bug 329075
__gsignals__ doesn' t work in classes derived from gst.Pipeline
Last modified: 2006-07-02 15:44:16 UTC
Please describe the problem: Hi!, I was trying to use the __gsignals__ class attribute to define some signals of my own in a Python class derived from gst.Pipeline, but connecting or emitting the signal fails with an 'unknown signal' error. Using __gsignals__ with classes derived directly from gobject.GObject or, say, from one of the GTK classes, works properly. Steps to reproduce: 1. Run the attached pygst-signals.py Actual results: This is the output I get from pygst-signals.py: masoft:~/Desktop/Projects/seamless-devel$ python pygst-gsignals.py Signal emitted on object '<MyGObject object (__main__+MyGObject) at 0xb70295f4>'Signal emitted on object '<MyLabel object (__main__+MyLabel) at 0xb702961c>' Traceback (most recent call last):
+ Trace 65709
p.connect('my-signal', handler)
my-signal Expected results: I would expect the exception at the end not to happen. Does this happen every time? Yes Other information:
Created attachment 58320 [details] Test program that shows the described problem.
Call self.__gobject_init__() instead of chaning to the normal constructor. I believe it's because gst.Element overrides __new__.
(In reply to comment #2) > Call self.__gobject_init__() instead of chaning to the normal constructor. > > I believe it's because gst.Element overrides __new__. > It works indeed, thanks Johan. It is, however, pretty confusing that you have to do this sometimes. I still think this is a problem.
(In reply to comment #3) > (In reply to comment #2) > > Call self.__gobject_init__() instead of chaning to the normal constructor. > > > > I believe it's because gst.Element overrides __new__. > > > > It works indeed, thanks Johan. It is, however, pretty confusing that you have > to do this sometimes. I still think this is a problem. > It is indeed a problem, something to do with constructors. If you chain up to gst.Object.__init__() or gst.Element.__init__() it works fine, but it doesn't if you chain up to gst.Bin.__init__() or gst.Pipeline.__init__().
The reason why this fails is because we are using gst_bin_new() and gst_pipeline_new() as the constructors for gst.Bin and gst.Pipeline. Those constructors will override the associated gobject contained in a PyGObject (where a lot of stuff was setup). We need to use the new properties system proposed in #313138 in order for the object to be created the regular way (via py_gobject_constructv()).
Works fine with switch to new codegenerator and use of constructors. Marking bug as fixed.