Re: [pygtk] What are the restrictions on hanging new signals on the widget tree?
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
Re: [pygtk] What are the restrictions on hanging new signals on the widget tree?
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__?
James> Does the above comments help?
Yes, thanks. (My other alternative was to hang my new signals off
gtk.Widget...)
Skip
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] What are the restrictions on hanging new signals on the widget tree?
Skip Montanaro wrote:
>Using the Gtk 2.0 API, I have a subclass of GtkEntry to which I've attached
>three new signals: history-prev, history-next, and history-menu:
>
>class _HEntry(gtk.Entry):
>def __init__(self, *args):
>gtk.Entry.__init__(self, *args)
>self.set_name("_history_")
>
>gobject.signal_new("history-prev", _HEntry,
> gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION,
> gobject.TYPE_NONE, ())
>
>gobject.signal_new("history-next", _HEntry,
> gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION,
> gobject.TYPE_NONE, ())
>
>gobject.signal_new("history-menu", _HEntry,
> gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION,
> gobject.TYPE_NONE, ())
>
The above code creates a python subclass of GtkEntry, but at the C level
(where all the signal handling takes place), your _HEntry is still just
a GtkEntry (take a look at _HEntry.__gtype__). At the moment, you need
to explicitly create a new GType for your subclass. Your _HEntry def
should look like:
class _HEntry(gtk.Entry):
def __init__(self):
gobject.GObject.__init__(self)
self.set_name("_history_")
gobject.type_register(_HEntry)
Note the gobject.type_register() call, and chaining to GObject.__init__ rather than
gtk.Entry.__init__. If you look at _HEntry.__gtype__, it should be for This way, the
signals will be added to your new type rather than GtkEntry. This will also change
the type name used in the gtkrc file. The type name is generated from the full class
name (module.class), with dots replaced with plus signs (because Tim doesn't want to
make dots valid in type names).
>
>
>I want to add the same signals to a subclass of GtkSpinButton:
>
>class _HSpinButton(gtk.SpinButton):
>def __init__(self, *args):
>gtk.SpinButton.__init__(self, *args)
>self.set_name("_history_")
>
>gobject.signal_new("history-prev", _HSpinButton,
> gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION,
> gobject.TYPE_NONE, ())
>
>gobject.signal_new("history-next", _HSpinButton,
> gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION,
> gobject.TYPE_NONE, ())
>
>gobject.signal_new("history-menu", _HSpinButton,
> gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION,
> gobject.TYPE_NONE, ())
>
GtkSpinButton is a GtkEntry, and your above code added the signals to
GtkEntry (so they are visible in GtkSpinButton). Registering a new type
for _HSpinButton is probably the right option here as well.
>
>
>When I try this, the signals seem to be defined for my GtkEntry subclass
>just fine, but I get a Gtk warning and Python RuntimeError exception when
>trying to attach the signals to the GtkSpinButton subclass:
>
>History.py (pid:18736): GRuntime-WARNING **: gsignal.c:1147:g_signal_newv():
>signal "history_prev" already exists in the `GtkEntry' class ancestry
>Traceback (most recent call last):
> ...
> File "/home/skip/src/tttech/projects/SW/lib/python/TGW/Spinner.py", line 19, in
>?
>gobject.TYPE_NONE, ())
>RuntimeError: could not create signal
>
>This is a bit frustrating. I thought the restriction on signal names was
>that a direct ancestor of the class to which I was adding a signal couldn't
>already be using this signal name. It seems to me that I need to add these
>three signals rather high up in the widget hierarchy, which unfortunately
>will pollute a lot of widgets that have no use for them with these signals.
>Is there an alternative?
>
Does the above comments help? See the examples/gobject/signals.py
program for an example of registering new types.
James.
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
[pygtk] What are the restrictions on hanging new signals on the widget tree?
Using the Gtk 2.0 API, I have a subclass of GtkEntry to which I've attached
three new signals: history-prev, history-next, and history-menu:
class _HEntry(gtk.Entry):
def __init__(self, *args):
gtk.Entry.__init__(self, *args)
self.set_name("_history_")
gobject.signal_new("history-prev", _HEntry,
gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION,
gobject.TYPE_NONE, ())
gobject.signal_new("history-next", _HEntry,
gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION,
gobject.TYPE_NONE, ())
gobject.signal_new("history-menu", _HEntry,
gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION,
gobject.TYPE_NONE, ())
I want to add the same signals to a subclass of GtkSpinButton:
class _HSpinButton(gtk.SpinButton):
def __init__(self, *args):
gtk.SpinButton.__init__(self, *args)
self.set_name("_history_")
gobject.signal_new("history-prev", _HSpinButton,
gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION,
gobject.TYPE_NONE, ())
gobject.signal_new("history-next", _HSpinButton,
gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION,
gobject.TYPE_NONE, ())
gobject.signal_new("history-menu", _HSpinButton,
gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION,
gobject.TYPE_NONE, ())
When I try this, the signals seem to be defined for my GtkEntry subclass
just fine, but I get a Gtk warning and Python RuntimeError exception when
trying to attach the signals to the GtkSpinButton subclass:
History.py (pid:18736): GRuntime-WARNING **: gsignal.c:1147:g_signal_newv():
signal "history_prev" already exists in the `GtkEntry' class ancestry
Traceback (most recent call last):
...
File "/home/skip/src/tttech/projects/SW/lib/python/TGW/Spinner.py", line 19, in ?
gobject.TYPE_NONE, ())
RuntimeError: could not create signal
This is a bit frustrating. I thought the restriction on signal names was
that a direct ancestor of the class to which I was adding a signal couldn't
already be using this signal name. It seems to me that I need to add these
three signals rather high up in the widget hierarchy, which unfortunately
will pollute a lot of widgets that have no use for them with these signals.
Is there an alternative?
Thx,
Skip
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
