Skip Montanaro wrote:
> James> class _HEntry(gtk.Entry):
> James> def __init__(self):
> James> gobject.GObject.__init__(self)
> James> self.set_name("_history_")
> James> gobject.type_register(_HEntry)
>
> James> Note the gobject.type_register() call, and chaining to
> James> GObject.__init__ rather than gtk.Entry.__init__. If you look at
> James> _HEntry.__gtype__, it should be for This way, the signals will be
> James> added to your new type rather than GtkEntry. This will also
> James> change the type name used in the gtkrc file. The type name is
> James> generated from the full class name (module.class), with dots
> James> replaced with plus signs (because Tim doesn't want to make dots
> James> valid in type names).
>
>Thanks, I never would have guessed that. How come there is no need to chain
>through gtk.Entry.__init__?
>
Initialisation of GObjects is already a two part process. Each new type
declares an instance init function. C calls like gtk_entry_new() first
call a gobject funciton to create the instance object, which calls the
instance init functions for the superclasses in order (GObject down to
GtkEntry in this case).
Sometimes the function like gtk_entry_new() may do some extra
initialisation after creating the instance (in the case of GtkEntry, it
doesn't). The GObject.__init__ constructor (and
GObject.__gobject_init__ which is a synonym which doesn't get overriden
by subclasses) just calls the g_object_new() function with the GType of
the class (it uses the __gtype__ attribute to find this).
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
