Re: making Python GStreamer plugins work
- From: John Ehresman <jpe wingide com>
- To: Owen Taylor <otaylor redhat com>
- Cc: pygtk daa com au, GTK Dev List <gtk-devel-list gnome org>, muppet <scott asofyet org>, gstreamer-devel lists sourceforge net, in7y118 public uni-hamburg de
- Subject: Re: making Python GStreamer plugins work
- Date: Sat, 30 Apr 2005 12:25:01 -0600
Owen Taylor wrote:
I think it should be possible to do basically the same thing in Python
by creating the GObject out of GObject.__new__() rather than out of
GObject.__init__().
This would break backwards compatibility.
__new__() calls g_object_new() calls ... ->init() which allocates
the python object and binds it to the GObject
This is not 101% compatible with the current system but all the
incompatible cases I can come up with are pretty artificial (*)
It would break this:
class MyButton(gtk.Button):
def __init__(self):
gtk.Button.__init__(self, 'My Default Text', True)
This could be rewritten to use __new__, but it would need to be rewritten.
But in such cases all GObject additions would be would be a slightly
cleaner version of John's technique of passing data to the constructor
via magic properties... whether the constructor triggers GObject
creation or whether GObject creation triggers the constructor is
going to make a difference in how things are ordered.
Yes, using a magic property is a bad idea -- there's a reason the patch
was never committed. It's better to use thread local storage, although
that depends on no callback occurring between the call to g_object_new
and the GType constructor. For bindings that have the language specific
constructor trigger GObject creation (like pygtk), it would be better to
have a factory function that would get all the properties passed in and
be responsible for returning a valid GObject.
John
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]